IPFW2 ve -stable a aktualizace source upgrade

[Martin Horcicka]

Martin Horcicka (2002-08-05 17:00 +0200):

> Roman Neuhauser (2002-08-05 13:10 +0200):
>
> > > > > Juknete pro inspiraci sem
> > > > >
> > > > > http://www.freebsd-howto.com/HOWTO/Ipfw-Advanced-Supplement-HOWTO
> > >
> > > zacinam se v obecnosti teto diskuze trochu ztracet - nemohli bychom se
> > > dostat do konkretnejsi roviny? Treba, ze by nektery odpurce IPFW
> > > napsal nejaky kousek firewallu, ktery podle nej nejde udelat s IPFW
> > > efektivne? Ten vynatek nahore zrejme uplne nechapu.
> >
> >     jde o to, ze ipfw, advanced stateful rules (keep-state/check-state)
> >     a natd jdou dohromady jenom tak, ze prohodite poradi divertu a
> >     ostatnich pravidel, takze kazdy paket projde dynamickymi (dynamicky
> >     tvorenymi) pravidly dvakrat. ale to jen prekladam co je napsano v te
> >     citaci nahore, a cele je to popsano na te url, ktera je taky v
> >     tomhle mailu.
> >
> >     se setup / established tenhle problem neexistuje.
> >
> >     "The simplest and best solution to the advanced stateful rules
> >     problem is to use 'user ppp -nat' for all dialup ISP environments
> >     and have no divert natd rule in the ipfw rules file."
>
> Dobra, prinutili jste me to precist. :-) Autor, mi pripada ponekud paranoidni
> na nepravem miste a trochu zmateny, ale dejme tomu. Nejsem si stale jeste
> uplne jisty v cem je hlavni problem, ale mam urcite tuseni - srovnejme dve
> varianty:
>
> A.
>
> ...
> divert natd all from any to any via $oif
> ...
> check-state
> ...
> add allow ... out via $oif ... keep-state
> ...
>
> Tuhle variantu pouzil autor clanku. Uvazujme ted jen prochazeni na vnejsim
> rozhrani $oif - pri zpracovani paketu jdouciho smerem ven se v paketech z
> vnitrni site nejdrive prelozi zdrojova adresa (divert natd) a pak se teprve
> kontroluje tabulka dynamickych pravidel (check-state) a pridavaji se nova
> dynamicka pravidla (add ... keep-state). Dynamicka pravidla tedy obsahuji uz
> prelozenou (vnejsi) adresu. Pri zpracovani paketu jdouciho smerem dovnitr se
> nejdrive prelozi cilova adresa (divert natd) a pak se prochazi tabulka
> dynamickych pravidel (check-state), ovsem ten paket ma v tu chvili uz privatni
> cilovou adresu, takze v te tabulce pro nej pravidlo rozhodne nebude! Autor
> clanku to obchazi vytvorenim dvou dynamickych pravidel misto jednoho - tedy
> jednoho s privatni adresou a druheho s verejnou adresou, coz mi pripada
> prinejmensim uchylne. ;-)
>
> B.
>
> ...
> divert natd all from any to any out via $oif
> ...
> check-state
> ...
> add allow ... out via $oif ... keep-state
> ...
> divert natd all from any to any in via $oif
> ...

Je videt, ze takhle dlouhe maily uz asi nikdo necte, jinak byste me uz davno
museli roznest na kopytech. Varianta B je samozrejme naprosto nesmyslna,
protoze ty spravne prichozi pakety by se diky check-state k tomu druhemu
pravidlu divert nikdy nedostaly (uvedomil jsem si to vcera v noci). Velice se
vsem omlouvam za sireni takovehoto nesmyslu - ja uz tu dovolenou fakt
potrebuju. :-)

Nicmene, premyslel jsem o tom jak by to slo udelat jinak a nenapadlo me zadne
reseni, ktere by slo udelat v jednom pruchodu - tedy jen na vnejsim rozhrani.
Nenapadlo me ovsem ani jak dokazat, ze to pripadne vubec nejde. Navic,
i rozdeleni te funkcnosti na vnitrni a vnejsi rozhrani routeru ma urcite
nevyhody - myslim, ze bud bude dohromady zbytecne hodne tech pravidel s
keep-state a nebo bude hodne tech dynamicky vytvorenych pravidel - tak to
delal autor clanku a ta jeho varianta bude asi o neco lepsi, protoze ta
dynamicka pravidla by se snad mohla dat v jadre prohledavat efektivneji -
napr. nejakych hasovanim - ale nevim jak se to deje ve skutecnosti.

Kazdopadne se mi zda, ze to ve vsech pripadech nebude fungovat pri pouziti
privatni IP adresy pridelene vnitrnimu rozhrani toho routeru - coz by ovsem
snad az tak nevadilo.

Jeste jednou se omlouvam za ten nesmysl.

Martin