DHCP server, DHCP relay - delsi

[Dan Lukes]

Josef Brzak napsal/wrote, On 08/20/06 12:28:
>   >> OK, server posle odpoved routeru (DHCP relay) tj. DHCPOFFER ten 
>   >> prijde na router (DHCP relay), ale ten uz neposle DHCPREQUEST
>   >> na DHCP server. Doufam, ze jsem to popsal dobre :-).
>  
>   > Ne, nepopsal. Ve hre jsou tri pocitace. Klient, relay a server. 

>   DHCPOFFER neprijde na klienta tj.
>   pozadavek normalne prijde na server, ten odesle DHCPOFFER, ale klient
>   uz nic nedostane. Na relay DHCPOFFER prijde.

	OK. Takze, DHCPDISCOVER projde bez problmu az na server. Zpetne jdouci 
DHCPOFFER je spatren naposledy na vstupu do relaye a od te doby je 
pohresovan.

	Moznosti:
1. firewall na vstupu do relaye
2. Chybny offer (paket neobsahuej korektni informace proto, aby mohl byt 
relayovan puvodnimu tazateli)
3. chybna konfigurace DHCP relaye
4. firewall na vystupu

	Bohuzel, v tomto miste srozumitelne informace konci. Dalsi informace 
jsou bud' zmsatene, nebo navzajem si odporujici.

	Jestlize OFFER nedorazil na klienta, pak klient neodeslal REQUEST - a 
ten nemohl byt na RELAY spatren.

	Zcela nejasno mam i co se tyce prohazovani serveru z Linuxu na BSD. 
Nevim, jestli se prohazuje jen server (a relay tram je stejny v obou 
pripadech) nebo jestli se snazite rict, ze kdyz rozjedete ten server 
primo na tom Linuxu, kde jindy bezi relay, tak to funguje (pak ale 
pravdepodobne neni rozdil v Linux kontra FreeBSD, ale v Relay kontra bez 
relaye).

	Zkoumat masky a nastaveni jednotlivych interfacu na kteremkoliv ze 
zucastnenych stroju je v teto chvili predcasne.

	To prijde na radu az bude jasne, na kterem stroji se hanshaking 
prerusuje - a pak to budeme zkoumat predevsim na nem (a maximalne na 
tom, kdo je pred nim).

	Ocenuju snahu podat co nejvic informaci, ale v tomto pripade je to snad 
i naskodu, protoze se v nich nedokazu orientovat (alespon ja). Napriklad 
ten strace mluvi o DHCP REQUESTu, ktery ale podle vsech predchozich 
informaci zadny neexistuje. Takze tato informace aso pochazi z nejakeho 
pokusu, kdy byla sit v nejake jine konfiguraci, nez jaka nam byla zatim 
popisovana - nebo tomu proste nerozumim.

	Takze jeste jednou a pomalu. DHCP s relayem funguje takto:
klient posle DISCOVER na relay
relay preposle DISCOVER na server
server odpovi OFFER na relay
relay preposle OFFER kleintovi
klient posle REQUEST na relay
relay preposle REQUEST serveru
... sice to pokracuje, ale tohle by nam pro tuto chvili stacilo.

	Kazdy takovy paket musim tcpdumpem videt jednak na vystupu stroje, 
ktery ho odesla, jednak na vstupu stroje, ktery ho prijima. To jsou 
celkem ctyri SOUCASNE spustene tcpdumpy (klient, server, 2xrelay)

	Az poprve paket neuvidite ve vsech ctyrech tcpdumpech, tak jste narazil 
na problem. V te chvili je potreba rict co jste presne videl a kde jeste 
(a kde uz ne).

	Jestlize muzete na miste serveru mit dva ruzne (treba FreeBSD a Linux) 
a NIC DALSIHO se nezmeni (to jest, stale je tam po ceste stejny relay se 
stejnou konfiguraci), pak ma smysl zkusit obemoznosti a rict vysledek v 
obou moznostech. Pokud se budou lisit, muze to neco napovedet. Pokdu se 
ale v souvislosti s touto zmenou meni jest eneco dalsicho (treba vypadne 
ten relay) tak to skoro nema smysl - takove dva vysledky jsou prilis 
neporovnatelne.

	Jestlize bude rec o nejakem paketu, musi byt vzdy jasne receno, OBOJI - 
odkud a kam sel - (jen jedna z techto dvou informaci je malo ; a v 
konfiguraci s relayem paket NIKDY nejde z klienta na server - vzdy jde 
nejdriv z klienta na relay a pak teprve z relaye na server).

	Az budeme mit timto zpusobem zcela jasne nalezeno misto, kde se pakety 
ztraci, zacneme se zabyvat timto mistem s otazkou "proc" - driv ne. Ale 
dokud nevime jasne "kde" je otazka "proc" k zodpovezeni zbytecne obtizna ...


						Dan

-- 
Dan Lukes                                   SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz