Dotaz: jak funguje DHCP

[Pavel]

Zdravím všechny, snažím se dynamicky měnit IP záznamy v DHCPD serveru, avšak pokud změním IP na 10.100.200.20, začne se klient několikráte ptát na adresu, přičemž po tuto dobu(cca 5s) vypadne komunikace. V systémovém logu dhcp se objevuje:

DHCPDISCOVER from 00:0c:42:24:3c:84 via eth0.22
DHCPOFFER on 10.100.200.2 to 00:0c:42:24:3c:84 via eth0.22
DHCPREQUEST for 10.100.200.20 (10.100.200.1) from 00:0c:42:24:3c:84 via eth0.22: lease 10.100.200.20 unavailable.
DHCPNAK on 10.100.200.20 to 00:0c:42:24:3c:84 via eth0.22
uid lease 10.100.200.108 for client 00:0c:42:24:3c:84 is duplicate on 10.100.200.0/24
DHCPDISCOVER from 00:0c:42:24:3c:84 via eth0.22
DHCPOFFER on 10.100.200.2 to 00:0c:42:24:3c:84 via eth0.22
DHCPREQUEST for 10.100.200.20 (10.100.200.1) from 00:0c:42:24:3c:84 via eth0.22: lease 10.100.200.20 unavailable.
DHCPNAK on 10.100.200.20 to 00:0c:42:24:3c:84 via eth0.22
uid lease 10.100.200.108 for client 00:0c:42:24:3c:84 is duplicate on 10.100.200.0/24
DHCPDISCOVER from 00:0c:42:24:3c:84 via eth0.22
DHCPOFFER on 10.100.200.2 to 00:0c:42:24:3c:84 via eth0.22
DHCPREQUEST for 10.100.200.20 (10.100.200.1) from 00:0c:42:24:3c:84 via eth0.22: lease 10.100.200.20 unavailable.
DHCPNAK on 10.100.200.20 to 00:0c:42:24:3c:84 via eth0.22
uid lease 10.100.200.108 for client 00:0c:42:24:3c:84 is duplicate on 10.100.200.0/24

Pokud vrátím záznam zpátky na 10.100.200.2 vše funguje správně:

DHCPREQUEST for 10.100.200.2 from 00:0c:42:24:3c:84 via eth0.22
DHCPACK on 10.100.200.2 to 00:0c:42:24:3c:84 via eth0.22

Restart klienta(Mikrotik) nepomáhá, restart celého serveru si nemohu dovolit.

V dhcpd.conf mám:

ddns-update-style none;
authoritative;

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;


# 10.100.200.0
subnet 10.100.200.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option broadcast-address 10.100.200.255;
	option domain-name-servers 10.100.200.1;
	option routers 10.100.200.1;
	authoritative;
	max-lease-time 60;
	default-lease-time 60;
	range 10.100.200.100 10.100.200.199;

# AP1_MK
	host AP1_MK {
		hardware ethernet 00:0C:42:24:3C:84;
		fixed-address 10.100.200.20;
		}
	
	
	}

Tu minutu tam mám pouze pro testovací účely...

Odpovědi

[Pavel]

Tak se mi povedlo restartovat server bez toho aby to někdo poznal a zjistil jsem, že po restartu si to vezme "bez keců" správnou IP. Spíš mi to celé připadá jako kdyby tam běřeli dva DHCP servery. Pokud ho totiž vypnu, zapisuje se stále do logu a klientům je přidělena ta původní IP adresa.

[Kit]

Restart DHCP serveru běžně trvá do jedné sekundy, toho by si neměl nikdo všimnout ani za plného provozu.

[Filip Jirsák]

Pokud má klient přidělenu IP adresu přes DHCP a vyprší doba zápůjčky, pokouší se získat znovu tu samou. Navíc DHCP server tam má k tomuhle klientovi poznamenánu ještě IP adresu .108. Podle mne DHCP není určené k tomu, abyste dynamicky za běhu měnil IP adresy klientů. Je určené k tomu, aby se na začátku přidělila IP adresa, a tu se pak obě strany snaží zachovat.

[Pavel]

Právě, že z dhcpd.leases jsem záznam odstranil a hlášku to píše stejně. Restart nepomůže, je potřeba DHCP server na delší dobu vypnout.

[lertimir]

V logu je to naprosto jasná posloupnost.

1. Discover je broadcast žádost klienta
2. Offer je nabídka serveru. nabízí 200.2
3. Request je požadavek klienta. V rozporu s nabídkou požaduje 200.20
4. NAK je Nagative Acknowledgment. Fakticky zákaz použití adresy v request, a klient musí znovu požádat o novou.

Jak píše Filip, server není zařízen na dynamické změny za běhu. V /var/lib/dhcpd/dhcpd.leases jsou vidět všechny zápujčky adres, které server udělal.

[Pavel]

No, a právě ta posloupnost mi není jasná. Po změně nastavení DHCP, je vyslána žádost od klienta. Server, ač má záznam pro 200.20 nabízí 200.2. Naopak klient, původní adresa byla 200.2 požaduje novou 200.20. Takto je to v logu ihned po změně konfigurace. Takže ke klientovi se nějak, že má používat novou IP, žádá o ní, ale server mu jí nechce dát.

Pokud stopnu server na minutu a více - nevím jestli to má nějakou souuvislost s max-lease-time - tak pak přiděluje adresy normálně.

Pokud tedy není na dynamické změny, takže pokud pouze takto nastavím statickou IP z původní dynamické, bude to v pohodě?

[lertimir]

Tak spustit na serveru a klientu wireshark/tcpdump vyfiltrovat na DHCP a zjistit, co se skutečně pošle a kdy. Myslím, že tohle skoro nikdo neřeší, protože naopak ta částečné statičnost je to, co uživatelé mají rádi.

[Pavel]

Ano, taky bych to neřešil, kdyby to chodilo jak má. Teď jsem ovšem zjistil, že rezervace nemusí být přímo v tom subnetu, ale klidně mohou být až na konci souboru, všechny přiřazený k top-level. Server si pak vybere podle subnetu správný záznam. A co víc, lze přitom s klientem cestovat, ne že bych to měl v úmyslu, ale občas to potřebuji.

[pavlix]

Ano, taky bych to neřešil, kdyby to chodilo jak má.

Pokud by to nechodilo, jak má, měl by znít dotaz úplně jinak.

[pavlix]

protože naopak ta částečné statičnost je to, co uživatelé mají rádi.

Přesně tak.

[Pavel]

Tak jsem to již vytvořil k obrazu svému, v php vygeneruju z mysql dhcp.conf. Jak ale zařídit restart DHCP služby? Příkaz exec("/etc/init.d/isc-dhcp-server stop") nebo exec("stop isc-dhcp-server") nic neprovede.

[Petr Šobáň]

Práva!

Prostě to někam dát a cronem pod rotem kontrolovat přepsat config a restartovat službu.

Případně nastavit sudo.

[Filip Jirsák]

Já si pořád myslím, že vám to nebude moc fungovat, protože DHCP protokol není navržený k vnucování změn IP adres. Můžu se zeptat, k čemu to celé má být dobré? Nějak mi uniká smysl toho vnucovat klientovi jinou IP adresu, když už má nějakou zapůjčenou a má na ní třeba navázaná spojení.

[Pavel]

Zatím to funguje. Používáme to k jednodušší autorizaci uživatelů do sítě. Uživatel se připojí do sítě a při přístupu na web je přesměrován na přihlašovací stránku. Po ověření je uložen záznam do DHCP o nové IP a jsou pro přidělenou IP adresu povoleny pravidla ve FW.

Nad tím běží script, který to celé kontroluje, například uživatel musí používat pořád DHCP klienta, mít stejnou MAC,...

Klientovi dávám jinou IP kvůli přehlednosti - mám tak snadný přehled podle IP v jaké fázi se klient nachází. Routování se děje až u zákazníka, pokud vůbec, proto si mohu dovolit takové ověřování.

[Jary]

Akorát to máš určitě díravé. IP adresa se dá podvrhnout. MAC taky. Tím se můžu tvářit jako někdo jiný. Zkus raději hotové řešení radius

[pavlix]

+1

Radius je dobré řešení, kde kromě IP adres člověk může sledovat i přidělená uživatelská jména.

[Max]

Přesně tak, nechápu, proč nevyužít již stáající řešení, tzn. Radius server + nějaký Captive portál k tomu, např. CoovaChilli, RadiusDesk apod.
Zdar Max

[pavlix]

Po ověření je uložen záznam do DHCP o nové IP a jsou pro přidělenou IP adresu povoleny pravidla ve FW.

Pokud se tak jako tak mění nastavení firewall pro danou IP, pak nevidím jediný rozumný důvod, proč tu IP měnit a proč nepoužít pro daného klienta od začátku jen jednu IP. Celé to působí jako extrémně složité řešení relativně jednoduchého problému.

Klientovi dávám jinou IP kvůli přehlednosti - mám tak snadný přehled podle IP v jaké fázi se klient nachází.

Osobně bych to vnímal spíše jako zhoršení přehlednosti. V jaké fázi se který klient nachází je mnohem jednodušší sledovat, pokud klientovi zůstává stejná IP, ke které je jen přiřazený jiný stav.

Routování se děje až u zákazníka, pokud vůbec, proto si mohu dovolit takové ověřování.

Tato věta nedává smysl. Routování se děje na každém routeru ;).

[lertimir]

Mě to připadá jako ručně zbastlený Captive portal. Pokud už jít tímto směrem, tak bych použil standardní řešení viz odkazy, u něhož se dá očekávat, že už někdo používá a je vyzkoušené.

[j]

Jak uz bylo receno, mas to deravy jak reseto, navic pokud chces resit prava pristup k siti, tak se na to pouziva 802.1X. Klient se autorizuje (trebas vuci zminenymu radius serveru) a nasledne je mu pridelena prislusna sit - vcetne rozsahu IP samo.