problem s BINDem / dhclient

[Miroslav Lachman]

Dan Lukes wrote on 2019/04/29 00:37:

> To vypada jaki 'IPFilter' syntaxe. 

Neni to IPFilter, je to PF, ale maji dost podobnou syntaxi

> I tak se mi ale nezda, ze by tohle pravidlo mohlo zajistit obousmerny 
> pruchod DHCP paketu.
> 
> Obavam se, ze 'keep state' zaridi, ze z "protismeru" jsou dovoleny 
> pakety kde zdrojove a cilove adresy a portu jsou navzajem prohozeny. No 
> to ale u DHCP casto neplati. Dotaz odchazi z 0.0.0.0:67 na 
> 255.255.255.255:68, ale vraci se z IP adresy DHCP serveru na IP adresu 
> tazatele (ktery ji jeste nezna!) pripadne take na broadcast.

To mas asi pravdu, nicmene, jak jsem popsal v dalsim e-mailu, tak po 
"povoleni" adresy toho DHCP serveru uz to funguje. A je mozne, ze by to 
fungovalo i bezh tech dvou pravidel, i kterych ty stejne tvrdis, ze je 
mam obracene. Coz je klidne mozne, protoze v jednom pokusu jsem je mel 
prehozene tak, jak rikas, ze by mely byt, ale protoze to nefungovalo, 
zkusil jsem je prohodit - protoze jsem na netu nasel obe dve varianty a 
jelikoz o fungovani DHCP mam jen hodne povrchni znalosti, tak z hlavy 
presne nevim, ze ktereho na ktery port ta komunikace ma jit.

Napriklad tady to maji from 67 to 68

https://docs.oracle.com/cd/E53394_01/html/E54829/pftask-exs.html

>> Zkusmo jsem pridal jmenovita pravidla, povolujici obousmerny provoz 
>> mezi porty 67 a 68
>>
>> pass in quick on bge0 proto udp from any port = 67 to any port = 68 
>> keep state
>> pass out quick on bge0 proto udp from any port = 68 to any port = 67 
>> keep state
> 
> Pravidlo na ktere jsi se odvolalaval nahore obsahuje 'pass out' az 
> kontextu se mi zda, ze ma povolovat vsechny odchozi pakety - tedy pakety 
> opoustejici stroj smerem "do dratu". Pak ale tyhle dve pravidla nejspis 
> nemuzou byt dobre. DHCP klient posila pakety "out" - z portu 67 na port 
> 68 serveru. No a server odpovida "in" a portu 68 na port 67. Me se zda, 
> ze to mas poskladane obracene.
> 
> No a ten keep state je tam patrne uplne navic, protoze, jak uz vyse 
> zmineno, DHCP odpoved nemusi prichazet z adresy na kterou sel dotaz ani 
> nemusi byt adresovana na IP ze dotaz odesel.

Tohle pravidlo, tak jak jsem ho poslal, je uz zprocesovane vlastnim PF, 
ktery tam keep state pridava automaticky.
Ve skutecnosti je to zapsane jako

pass in quick on $ext_if proto udp from port 67 to port 68
pass out quick on $ext_if proto udp from port 68 to port 67

> Ale ani prohozeni 'in' a 'out' neni zarukou, ze to bude spravne. Nevidim 
> v pravidlech 'quick', takze pruchod paketu muze stale zakazat i nejake 
> pozdejsi pravidlo - a netusim, co s tim udel;a ta "stavovost".
> 
> 
>> Ale v logu se mi zase objevilo dhclient[40538]: send_packet: 
>> Permission denied.
> 
> To podporuje moji hypotezu, ze to nemas dobre ;-)

Zda se, ze tenhle problem uz mam opravdu vyreseny, za coz ti patri muj 
dik, protoze bez tveho navedeni bych ani nevedel, v cem se mam stourat.

Takze ted se muzu obloukem vratit k puvodnimu tematu, BIND, ktery mi ted 
opet prestal odpovidat na dotazy z venku a to v dobe, kdy jsem se zrovna 
v nicem nestoural, vnejsi interface mel IP ziskanou v Apr 28 23:32:14.
V dhclient.leases.bge0 je tohle
   renew 1 2019/4/29 00:32:14;
   rebind 1 2019/4/29 02:47:14;
   expire 1 2019/4/29 03:32:14;

a v 01:00 prestal odpovidat na dotazy na vnejsi IP adrese. Tudiz tenhle 
problem nesouvisi ani s firewallem (s tim jsem v te dobe nic nedelal), 
ani s DHCP, protoze s nim podle zaznamu v logu v jednu hodinu taky nic 
neprobehlo.

Zvlastni je, ze podle vypisu netstat ted BIND prestal poslouchat na TCP 
portu, ale dal posloucha na UDP portu na te verejne adrese.

V BINDu mam zapnuty pomerne rozsahly logovani vseho mozne. Prohlidnul 
jsem logy, ale okolo 1:00 tam zadne errory nevidim.

Je mi jasne, ze z takto dodanych informaci mi dobrou radu muze dat leda 
vestec s kristalovou kouli, takze je tu to vlastne jen takova informace, 
kterou si sem odlozim a zitra se k tomu vratim...

Mirek