ipfw divert keep-state

[Dan Lukes]

>> 	Moc tomu nerozumim - ale neni nahodou NAT na vstupu stavovym
> filtrem
>> sam o sobe ? (propousti "dovnitr" pouze pakety odpovidajici spojenim,
>> ktee byly korektne navazane "ven").

> Je to tak. Moje puvodni uvaha byla takova, ze je zbytecne poustet k NATu
> packety, ktere neprosli smerem tam. 

	No, tim jsme patrne vyresili otazku, jestli je takove reseni nutne a 
vhodne. Ja jsem se ale nad tim trochu zamyslel jeste jednou a dospel 
jsem k zaveru, ze takovehle reseni predevsim nelze z principu vubec 
realizovat, cimz by se otazka vhodnosti a nutnosti stala irelevantni.

	Je potreba uvazit, ze z hlediska stavoveho firewallu je TCP spojeni 
prochazejici NATem dvema nezavislymi TCP spojenimi. Jelikoz nelze 
keep-state aplikovane na jedne strane NATu mixovat s check-state ve 
snaze udelat cokoliv s pakety na druhe strane NATu, je zrejme, ze 
keep-state a check-state se musi zabyvat pakety na stejne strane NATu.

	Jde-li ti o blokovani prichozich nepatricnych paketu, pak je zrejme, ze 
vyvolenou stranou musi byt strana "vnejsi". Jenze, tady musime na pakety 
aplikovat divert - aby se dostaly do NATu - a protoze na paket lze 
aplikovat pouze jedno pravidlo tak vubec nema smysl uvazovat o 
check-state. Nemuzeme-li pouzit check-state, nema valneho smyslu 
pouzivat keep-state cimz jsme firewall uspesne "odstavovali" na bezny, 
bezestavovy.

	Skoro se mi zda, ze jsem exhaustivne prosel vsechny vetve stromu 
moznych reseni a ve vsech se ukazalo, ze "takhle to resit nejde". Tim 
(za predpokladu, ze jsem zadnou neminul) bych "takhle to resit vubec 
nejde" povazoval za definitivni odpoved na otazku po moznosti chranit na 
vstupu NAT stavovym IPFW.

	Mozna by se podarilo nejakym zhuverilym zpusobem sesadit dohromady 
konfiguraci, kde by NAT bezel na vnitrnim interface, nebo mozna na 
loopbacku, ve ktere by problem resitelny byl, ale rekl bych, ze to za to 
opravdu nestoji ...


							Dan