DHCP ugibanje

Zgodba je precej dolga, zato se bom poskusila omejiti le na najpomembnejše (če bom kaj pozabila, pa vprašajte).

Preselili smo se (cela firma) na novo lokacijo in si potegnili svojo mrežo (zvezda) po svojem kompleksu stavb. Priklopili serverje in – juhej – vse dela BP.

Želja gospoda lastnika kapitala pa je bila, da bi imel ‘skupno računovodstvo’ (beri vse računovodkinje v eni sobi), zato se je moral naš oddelek računovodstva preseliti v drugi del kompleksa stavb. Ker pa imajo tam že svojo mrežo in bi bilo bogokletno tam karkoli ‘razbijati’ smo obe mreži povezali z enim kablom (switch to switch). V njihovih prostorih smo na njihovo obstoječo mrežo priklopili svoje mašine in sistemski tiskalnik in – naši DHCP, DNS, Exchange… serverji so poslušno postorili, kar jim je bilo zaukazano. :))

So far so good.

Pojavila pa se je težava. Naš DHCP server dodeljuje naše IP addresse tudi njihovim mašinam. (Baje imajo svoj DHCP in DNS server.) Tako imajo (uporabniki v drugi firmi) ob jutranji kavici še telovadbo, da jim po nekajkratnih restartih končno uspe pridobiti pravi (njihov) naslov.

Sedaj pa prosim vas, izkušene mačke, da poskušate z mano ugibati kakšne nastavitve imajo oz. kakšne bi morale biti.

Variante:

1. Svoje čurunalniški kabel do svojega serverja
2. Inteligenten switch in VLAN-e
3. Direktorja v /dev/null

Namreč DHCP sistem je TUP ko k****c, on pač pošilja svoje paketke po
svojem omrežju, in katera kartica se pač prijavi na njega, tista
dobi njegove podatke (sem pa napisal) :)))

Žal ni druge šanse..

Ugibam – ker imam premalo izkušenj s tem.

Kaj pa ‘automatic allocation’?
In kakšna kombinacija z DNS strežnikom?

Kaj pa ‘automatic allocation’?

Kje s’pa to najdla ??

Bom pisaril še 1x, bolj počasi:

– imate firmo (tut jest bi jo)
– imate DNS serverje, ki imajo omrežne naslove npr: do 192.168.1.100 – 192.168.1.xx
– imate en kabelj za eno in drugo firmo

– torej vsi računalniki na tem kablu dobivajo IP naslov iz istega DHCP strežnika, kar je čisto pravilno

šansa:
– potegneš še en kabel
in to je to

mogoče inteligenten switch (npr. cisco), pa narediš vlan-e v njem in potem vse deluje..

več pa ni.

imate DNS serverje, ki imajo omrežne naslove npr: do 192.168.1.100 – 192.168.1.xx

Tukaj je napaka, želel sem napisati namesto DNS DHCP seveda.

No je pa še ena rešitev:

– una ta druga firma, naj si vpiše fixne IP naslove, pa bo njim vse
delalo, vam bo pa DHCP vse dodeljeval pravilno ???

Se opravičujem, da se tako pozno spet oglašam.

Res, najbolj ziher rešitev bi bila svoj kabel – to vem že od začetka, AMPAK, saj veš vsi lezemo lastniku kapitala v rit 🙂
No, in ta kabel bom tudi potegnila (tudi preko trupel).

Verjetno se da to tudi softwersko rešit. Toda v mojih letih človek verjame da ‘vsi na svetu vse vedo in da se na vsem svetu tudi vse dobi’ (Martin Krpan) – in pa seveda raje vidim da se mi vse na pladnju prinese, kot da bi se mi skurla kakšna možganska celica preveč (edina?) – lenoritis!
Tako sem upala, da bo kdo zamahnil s čarobno palčko in rekel: Pojdi na xxx/yyy pritisni aaa in daj kljukico pri zzz – in to bi bilo to in jaz bi bila velik frajer in … 🙂

In kaj me je privedlo na to misel? Tole:

DHCP supports three mechanisms for IP address allocation. In “automatic allocation”, DHCP assigns a permanent IP address to a client. In “dynamic allocation”, DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). In “manual allocation”, a client’s IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.

Še bolj pa me je zrajcalo tole:

4.2 DHCP server administrative controls

DHCP servers are not required to respond to every DHCPDISCOVER and DHCPREQUEST message they receive. For example, a network administrator, to retain stringent control over the clients attached to the network, may choose to configure DHCP servers to respond only to clients that have been previously registered through some external mechanism. The DHCP specification describes only the interactions between clients and servers when the clients and servers choose to interact; it is beyond the scope of the DHCP specification to describe all of the administrative controls that system administrators might want to use. Specific DHCP server implementations may incorporate any controls or policies desired by a network administrator.

In some environments, a DHCP server will have to consider the values of the vendor class options included in DHCPDISCOVER or DHCPREQUEST messages when determining the correct parameters for a particular client.

A DHCP server needs to use some unique identifier to associate a client with its lease. The client MAY choose to explicitly provide the identifier through the ‘client identifier’ option. If the client supplies a ‘client identifier’, the client MUST use the same ‘client identifier’ in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a ‘client identifier’ option, the server MUST use the contents of the ‘chaddr’ field to identify the client. It is crucial for a DHCP client to use an identifier unique within the subnet to which the client is attached in the ‘client identifier’ option. Use of ‘chaddr’ as the client’s unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer’s serial number as the ‘client identifier’, to avoid unexpected changes in a clients network address due to transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the ‘client identifier’, causing address leases to be associated with the DNS name rather than a specific hardware box.

DHCP clients are free to use any strategy in selecting a DHCP server among those from which the client receives a DHCPOFFER message. The client implementation of DHCP SHOULD provide a mechanism for the user to select directly the ‘vendor class identifier’ values.

No kakor koli že – potegnila bom svoj kabel in za vedno ločila obe mreži.

Vseeno hvala za tvoj trud in čas. Pivo pa tudi dobiš ob prvi priliki…

Pa je res nujna uporaba DHCP-ja? Kaj pa, kot je že omenil klemen fiksni naslovi? Dodeliš pač vsakemu posebej stalno cifro in je mir – razen seveda, če nimaš več sto škatel 🙂

Se strinjam z klemenxx, sploh pri 3. točki.
To je najlažja rešitev.

Lahko pa mal kompliciramo, z tretjo rešitvijo:

Je rešitev a bo potrebno kar malo dela.
Obe mreži imata ločene naslove.
Ni kakšna posebna varnost, a vsaj običajni uporabniki ne vidijo drug drugega.

Na obeh DHCP setverjih je potrebno vnesti fiksno vezavo IP naslova mašine oz. tiskalnika in njegovega MAC naslova mrežne kartice.
Hkrati je potrebno onemogočiti dodeljevanje IP naslovov mašinam, ki nimajo fiksnega naslova.

Dal bi se dati tudi na en sam DHCp server.

Cena dela računalničarja za administracijo: verjetno nekje pri ceni 1 switch-a in par kablov.

Domnevam, da se ne oglašaš iz neke hudo velike firme, zato so fiksni IP naslovi možna rešitev. Probat ni greh. Že na domačih omrežjah, kjer več uporabnikov uporablja DC Plus je to nujna rešitev za aktiven dostop. V nasprotnem primeru se podatki spremenijo, brž ko se v omrežje poveže drug uporabnik.

Že že fixni IP. Kaj pa ko se nekdo hoče priključiti s prenosnikom?

Imaš lahko še vedno fiksne IPje na mašinah in za “goste” tudi dhcp. Fiksarji pač terajo svoje in ne šmirglajo dhcpja. Če so pa prenosniki redni uporabniki, se jim pa seveda da enostavno uredit tudi alternativno povezavo ( eno z avtomatskim poslušanjem dhcpja in drugo z fiksnim ipjem)