On 29.4.2019 0:56, Miroslav Lachman wrote:
V pf.conf mam tabulku "reserved":
table <reserved> { ..., 10.0.0.0/8, ..., 0.0.0.0/8, ... }
## Deny all non routable trafic on external interface
block log quick on $ext_if inet from <reserved> to any
block log quick on $ext_if inet from any to <reserved>
DHCP server ma adresu 10.128.129.89:
Takze 10.128.129.89 v tomto pripade "routable" je, a predpoklad "adresy
zpravidla nemaji co delat" konkretne tady neplati. Nejspis je ta adresa
dokonce primo directly-connected (protoze primarni RENEW se posila na
255.255.255.255)
Tuhle IP jsem tedy vyloucil z tabulky reserved:
table <reserved> { ..., !10.128.129.89 }
A zpravy "send_packet: Permission denied" uz se v logu nevyskytujou.
To vypada jako vitezstvi.
Ale ja bych tohle neresil pres adresy. Proste bych povolil jakekoliv
odchozi UDP z portu 67 na port 68 a prichozi UDP z portu 68 na port 67.
Tecka.
jestli UPC DHCP server ma vzdy adresu 10.128.129.89
I kdyby ...
Nechtel's pouzit statickou konfiguraci IP, protoze ti do toho UPC muze
kdykoliv stournout, zpravidla, kdyz si pryc, a prestane to fungovat.
Opravdu chces funkcnost uzamknout na predpoklad, ze nemeni adresu DHCP
serveru ? Uz zitra ten DHCP server muze byt na jine - myslim uplne jine,
tedy ani ne z 10.0.0.0/8
ten keep state je tam patrne uplne navic
PF, ktery tam keep state pridava automaticky
Koukam, ze se IPF vyhybam i z duvodu, ktery jsem ani neznal ... ;-)
vratit k puvodnimu tematu, BIND, ktery mi ted opet prestal odpovidat na dotazy
z venku
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.
BIND prestal poslouchat na TCP portu, ale dal posloucha na UDP portu
Ja bych hadal, ze inicializace poslouchani bud eresit TCP i UDP soucasne
a to, ze jedno zustane a adruhe ne se mi jevi navysost podezrele. No, to
uz je fakt na podivani se do zdrojaku a to ti nejmene ted nabidnout
nemuzu. A k tomu mozna bude potreba pustit BIND pod kdump, pravidelne
testovat kdy na tom TCP prestane pospichat (protoze ten dump bude
ohromny a bez casu se v tom kriticky okamzik bude velice tezce hledat) a
pak se s tim nejak poprat.
Dan
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
