iptables snat/dnat vs masquerade

[Aleksandar Ivanisevic]

Jel bi sad po novom trebalo trosit -j DNAT/SNAT umjesto MASQUERADE?
jel moze D/SNAT maskirat u dinamicki IP, tj. onaj koji nije poznat
u trenutku applayanja rulea?

--
Ivanisevicu, pokusaj se za promjenu drzati teme i replicirati na ono o
cemu sugovornik pise. Osim sto je tvoje pracenje "koji me vrag zapravo
muci" off-topic na Linux grupi, radi se i o zabadanju njuske u moje
privatne stvari. Vec si pokazao nedostatak dobrog odgoja no ovo granici
sa sociopatijom. -- Mladen Gogala, hr.comp.os.linux

[Dinko Korunic]

On Mon, 07 Jun 2010 10:29:54, Aleksandar Ivanisevic <aleks...@ivanisevic.de> wrote:
> Jel bi sad po novom trebalo trosit -j DNAT/SNAT umjesto MASQUERADE?
> jel moze D/SNAT maskirat u dinamicki IP, tj. onaj koji nije poznat
> u trenutku applayanja rulea?

Koliko znam (ne znam zasto velis po novom?), i SNAT i DNAT i dalje ocekuju
fiksni --to-source / --to-destination mapping, tako da MASQUERADE i dalje
ima svoju uobicajenu funkciju NATiranja...

--
NAME:Dinko.kreator.Korunic DISCLAIMER:Standard.disclaimer.applies
ICQ:16965294 JAB:kreat...@jabber.org PGP:0xEA160D0B
HOME:http://dkorunic.net QUOTE:Eat.right.stay.fit.and.die.anyway

[Jakov Sosic]

On Mon, 07 Jun 2010 10:29:54 +0200, Aleksandar Ivanisevic wrote:

> Jel bi sad po novom trebalo trosit -j DNAT/SNAT umjesto MASQUERADE? jel
> moze D/SNAT maskirat u dinamicki IP, tj. onaj koji nije poznat u
> trenutku applayanja rulea?

Odakle ti to "po novom"?

--
| Jakov Sosic | ICQ: 28410271 | PGP: 0x965CAE2D |
=================================================================
| start fighting cancer -> http://www.worldcommunitygrid.org/ |

[Dinko Korunic]

On Mon, 07 Jun 2010 11:37:46, Jakov Sosic <jso...@gmail.com> wrote:
>> Jel bi sad po novom trebalo trosit -j DNAT/SNAT umjesto MASQUERADE? jel
>> moze D/SNAT maskirat u dinamicki IP, tj. onaj koji nije poznat u
>> trenutku applayanja rulea?
>
> Odakle ti to "po novom"?

Mozda misli na to da se iptablesi planiraju obsoleteati u buducnosti...

[Aleksandar Ivanisevic]

Dinko Korunic <dinko....@gmail.com> writes:

> On Mon, 07 Jun 2010 10:29:54, Aleksandar Ivanisevic <aleks...@ivanisevic.de> wrote:
>> Jel bi sad po novom trebalo trosit -j DNAT/SNAT umjesto MASQUERADE?
>> jel moze D/SNAT maskirat u dinamicki IP, tj. onaj koji nije poznat
>> u trenutku applayanja rulea?
>
> Koliko znam (ne znam zasto velis po novom?), i SNAT i DNAT i dalje ocekuju
> fiksni --to-source / --to-destination mapping, tako da MASQUERADE i dalje
> ima svoju uobicajenu funkciju NATiranja...

Na znam, zato pitam. Direktan povod je vrlo cudna situacija sa
MASQUERADE targetom u openvz-u gdje ekipa tvrdi da to nikad nece bit
virtualizirano jer da treba trosit S/DNAT.

Kaje najbitnije stvar radi sasvim uredno, iako oni tvrde da ne radi,
jedino kaj modul treba loadat ne preko vz.conf nego eksterno sa
modprobe.

[Aleksandar Ivanisevic]

Jakov Sosic <jso...@gmail.com> writes:

> On Mon, 07 Jun 2010 10:29:54 +0200, Aleksandar Ivanisevic wrote:
>
>> Jel bi sad po novom trebalo trosit -j DNAT/SNAT umjesto MASQUERADE? jel
>> moze D/SNAT maskirat u dinamicki IP, tj. onaj koji nije poznat u
>> trenutku applayanja rulea?
>
> Odakle ti to "po novom"?

A kajaznam, ja se ajpitejblsma bavim sporadicno, moze se lako dogodit
da mi obsoletaju iza ledja kaj god oces. Kad tri puta guglam maskaradu
a izguglam S/DNAT, pocnem se pitat ;)

[Dinko Korunic]

On Mon, 07 Jun 2010 11:46:29, Aleksandar Ivanisevic <aleks...@ivanisevic.de> wrote:
> Na znam, zato pitam. Direktan povod je vrlo cudna situacija sa
> MASQUERADE targetom u openvz-u gdje ekipa tvrdi da to nikad nece bit
> virtualizirano jer da treba trosit S/DNAT.

WTF, uh.

> Kaje najbitnije stvar radi sasvim uredno, iako oni tvrde da ne radi,
> jedino kaj modul treba loadat ne preko vz.conf nego eksterno sa
> modprobe.

Exactly, i ja isto to tako trosim na valjda XY masina sa raznim OVZ
kernelima i patchevima i to radi OK. Nabrojim sve potrebne ipt_ i xt_
module i kasnije trosim te stvari u virtualkama i to radi OK.

[Jakov Sosic]

On Mon, 07 Jun 2010 09:42:21 +0000, Dinko Korunic wrote:

> On Mon, 07 Jun 2010 11:37:46, Jakov Sosic <jso...@gmail.com> wrote:
>>> Jel bi sad po novom trebalo trosit -j DNAT/SNAT umjesto MASQUERADE?
>>> jel moze D/SNAT maskirat u dinamicki IP, tj. onaj koji nije poznat u
>>> trenutku applayanja rulea?
>>
>> Odakle ti to "po novom"?
>
> Mozda misli na to da se iptablesi planiraju obsoleteati u buducnosti...

Koliko vidim pitanje je "jel bi _SAD_ po novom". Dakle nema smisla
raspravljati o necem sta ce se dogodit za X godina.

[Aleksandar Ivanisevic]

Dinko Korunic <dinko....@gmail.com> writes:

> Exactly, i ja isto to tako trosim na valjda XY masina sa raznim OVZ
> kernelima i patchevima i to radi OK. Nabrojim sve potrebne ipt_ i xt_
> module i kasnije trosim te stvari u virtualkama i to radi OK.

e a sad stavi ipt_MASQUERADE u IPTABLES varijablu u /etc/vz/vz.conf
ili di ti je vec, pa mi javi kaj se dogadja ;)

[Aleksandar Ivanisevic]

Jakov Sosic <jso...@gmail.com> writes:

> On Mon, 07 Jun 2010 09:42:21 +0000, Dinko Korunic wrote:
>
>> On Mon, 07 Jun 2010 11:37:46, Jakov Sosic <jso...@gmail.com> wrote:
>>>> Jel bi sad po novom trebalo trosit -j DNAT/SNAT umjesto MASQUERADE?
>>>> jel moze D/SNAT maskirat u dinamicki IP, tj. onaj koji nije poznat u
>>>> trenutku applayanja rulea?
>>>
>>> Odakle ti to "po novom"?
>>
>> Mozda misli na to da se iptablesi planiraju obsoleteati u buducnosti...
>
> Koliko vidim pitanje je "jel bi _SAD_ po novom". Dakle nema smisla
> raspravljati o necem sta ce se dogodit za X godina.

A cuj, ruku na srce, malo je to nedoreceno, meni ima logike da se u
SNAT doda --to interface i onda da to bude ekvivalenat
MASQUERADE-tu. Zakaj bi se stvar ako je fiksni ajpi zvala drugacije
nego kad je dinamicki ajpi, hu kerz?

[Davorin Vlahovic]

[Mon, 7 Jun 2010 09:42:21 +0000 (UTC)] Dinko Korunic je napisao/la:
> On Mon, 07 Jun 2010 11:37:46, Jakov Sosic <jso...@gmail.com> wrote:
>>> Jel bi sad po novom trebalo trosit -j DNAT/SNAT umjesto MASQUERADE? jel
>>> moze D/SNAT maskirat u dinamicki IP, tj. onaj koji nije poznat u
>>> trenutku applayanja rulea?
>>
>> Odakle ti to "po novom"?
>
> Mozda misli na to da se iptablesi planiraju obsoleteati u buducnosti...

Kaj, uzet ce pf ili sto? Ovo mi je promaklo...

--
Opsesivno ste kompulzivni. Prebrojali ste probleme i otkrili da ih imate 99.
Zeljeli biste imati 100 problema. Cinjenica da nemate 100 problema vas iznimno
muci - to je velik problem. Tako sada imate 100 problema. Medutim, sad kad
imate 100 problema cinjenica da nemate 100 problema vise nije problem i vratili
ste se na 99. Ali cinjenica da imate 99...

[Dinko Korunic]

On Tue, 08 Jun 2010 00:24:18, Davorin Vlahovic <nr...@ylf.krs.ref.rh> wrote:
>> Mozda misli na to da se iptablesi planiraju obsoleteati u buducnosti...
>
> Kaj, uzet ce pf ili sto? Ovo mi je promaklo...

Nece, ide alat (trenutno me muci da se nemrem sjetiti kako se zove) koji
ima drukciju i fleksibilniju sintaksu od iptablesa, a unutar kernela ide
nesto sto je vjerojatno Netfilter v2 :) Cak je bio razgovor ovdje na grupi
o tome, ali velim ne mogu se nikako sjetiti kako se zove taj novi alat --
nesto poput xtables ili nesto sl. :/ Bilo je o tome na LKML-u jos cak
prije godinu dana cca.

[Dalibor Dukic]

On Tue, 8 Jun 2010 09:47:38 +0000 (UTC), Dinko Korunic wrote:
> o tome, ali velim ne mogu se nikako sjetiti kako se zove taj novi alat --
> nesto poput xtables ili nesto sl. :/ Bilo je o tome na LKML-u jos cak
> prije godinu dana cca.

Mislis na nftables? http://lwn.net/Articles/324989/

--
Fashion is for people who have no style.

[Jakov Sosic]

On Thu, 10 Jun 2010 20:11:47 +0000, Dalibor Dukic wrote:

> On Tue, 8 Jun 2010 09:47:38 +0000 (UTC), Dinko Korunic wrote:
>> o tome, ali velim ne mogu se nikako sjetiti kako se zove taj novi alat
>> -- nesto poput xtables ili nesto sl. :/ Bilo je o tome na LKML-u jos
>> cak prije godinu dana cca.
>
> Mislis na nftables? http://lwn.net/Articles/324989/

Kako tuzno... uz odlican pf i solidan ipfilter, ovi moraju sve
ispocetka :) Imamo dojam da opet to nece bit to...

[Aleksandar Ivanisevic]

Jakov Sosic <jso...@gmail.com> writes:

> On Thu, 10 Jun 2010 20:11:47 +0000, Dalibor Dukic wrote:
>
>> On Tue, 8 Jun 2010 09:47:38 +0000 (UTC), Dinko Korunic wrote:
>>> o tome, ali velim ne mogu se nikako sjetiti kako se zove taj novi alat
>>> -- nesto poput xtables ili nesto sl. :/ Bilo je o tome na LKML-u jos
>>> cak prije godinu dana cca.
>>
>> Mislis na nftables? http://lwn.net/Articles/324989/
>
> Kako tuzno... uz odlican pf i solidan ipfilter, ovi moraju sve
> ispocetka :) Imamo dojam da opet to nece bit to...

Da si samo mrvicu dolje skrolnuo u komentare, sve bi ti bilo jasno,
iako bi ti trebalo bit jasno i bez da ti se crta.

Nftables: a new packet filtering engine

Posted Mar 25, 2009 3:26 UTC (Wed) by kaber (guest, #18366) [Link]
Indeed :)

To clarify: I certainly did consider the way pf does things and there
are quite a few things I like better than in iptables, starting with
having a language specifically designed for filtering rules, compared
to the quite primitive shell command invocation mainly used with
iptables.

But porting the kernel side doesn't make sense at all. The code
structure doesn't match how things are done in the Linux kernel, the
API doesn't match what we want, its tightly coupled to a different NAT
and state tracking system and even basic things like rule evaluation
order are different from what iptables does. There's no way to
transform it into something that can be backwards compatible with
iptables/ip6tables/arptables/ebtables without basically rewriting it.

[Jakov Sosic]

On Fri, 11 Jun 2010 10:26:19 +0200, Aleksandar Ivanisevic wrote:

> Da si samo mrvicu dolje skrolnuo u komentare, sve bi ti bilo jasno, iako
> bi ti trebalo bit jasno i bez da ti se crta.
>
> Nftables: a new packet filtering engine
>
> Posted Mar 25, 2009 3:26 UTC (Wed) by kaber (guest, #18366) [Link]
> Indeed :)
>
> To clarify: I certainly did consider the way pf does things and there
> are quite a few things I like better than in iptables, starting with
> having a language specifically designed for filtering rules, compared to
> the quite primitive shell command invocation mainly used with iptables.
>
> But porting the kernel side doesn't make sense at all. The code
> structure doesn't match how things are done in the Linux kernel, the API
> doesn't match what we want, its tightly coupled to a different NAT and
> state tracking system and even basic things like rule evaluation order
> are different from what iptables does. There's no way to transform it
> into something that can be backwards compatible with
> iptables/ip6tables/arptables/ebtables without basically rewriting it.

backwards compatibility je ionako za racku, pa to su firewall rulovi a ne
baze od 300GB... cim izadje alat, morat ces naucit novo pisanje pravila

a ovo oko internih struktura je jasno, no ako su mogli portat stvari
poput XFS-a, sumnjam da je firewall puno kompliciraniji. no u krajnju
ruku ne moraju ni portat, bitno je da vide koncepte i shvate ideje drugih
firewall sustava kod kojih su pravila puno citljivija i intiutivnija za
pisanje...

[Drazen Kacar]

Jakov Sosic wrote:

> a ovo oko internih struktura je jasno, no ako su mogli portat stvari
> poput XFS-a, sumnjam da je firewall puno kompliciraniji.

Vjerojatno nije, ali za file systeme u kernelima postoji API (koji obično
nije stabilan preko releasova) zato što je file systema puno i API je
pametno i poželjno imati. Pa ti je onda portanje puno jednostavnije jer
veliku većinu koda u file systemu ne moraš ni pogledati.

Firewall je, s druge strane, nešto što pušta pipke posvuda po networking
kodu, a API-ja obično nema jer je firewall jedina stvar s takvim
potrebama, pa je pravljenje nekakvog nivoa apstrakcije između njega i
networking koda gubitak vremena i energije.

> no u krajnju
> ruku ne moraju ni portat, bitno je da vide koncepte i shvate ideje drugih
> firewall sustava kod kojih su pravila puno citljivija i intiutivnija za
> pisanje...

Ja ne vidim zašto se za iptables ne bi mogao napisati programčić koji bi
parsirao file s čitljivijim pravilima, a onda to pretvorio u nečitljive
iptables inkantacije. I obratno. Pretpostavljam da nikoga nije dovoljno
svrbilo.

--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| da...@fly.srk.fer.hr

[Ivan Popovski]

On 2010-06-11, Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> Ja ne vidim zasto se za iptables ne bi mogao napisati programcic koji bi
> parsirao file s citljivijim pravilima, a onda to pretvorio u necitljive

> iptables inkantacije. I obratno. Pretpostavljam da nikoga nije dovoljno
> svrbilo.

Moja pretpostavka je zato sto su developeri u jednom trenu zabrijali da bi se
lib trebao ponasati kao baza. Pazi imas cak i commit :-)
Ali ovo o cemu ti pricas i postoji, ali je lib napravljen tako da se korisnik
ne mora zamarati s time, npr imas do_command koji prima argumente kao getopt i
pretvara ih u nesto necitljivo sto se prosljedjuje u kernelu ili stovec.
Programiranje toga lici vise na klepanje komandi. Za detalje si pogledaj
npr iptables-restore.c

[Aleksandar Ivanisevic]

Ivan Popovski <ip@nj.g> writes:

> On 2010-06-11, Drazen Kacar <da...@fly.srk.fer.hr> wrote:
>> Ja ne vidim zasto se za iptables ne bi mogao napisati programcic koji bi
>> parsirao file s citljivijim pravilima, a onda to pretvorio u necitljive
>> iptables inkantacije. I obratno. Pretpostavljam da nikoga nije dovoljno
>> svrbilo.
>
> Moja pretpostavka je zato sto su developeri u jednom trenu zabrijali da bi se
> lib trebao ponasati kao baza. Pazi imas cak i commit :-)

commit je bitan da bi promjena koja obuhvaca vise od jednog rulea bila
applayana atomicno, jerbo jedan rule kao takav moze znacit otvoren
firewall za one 3 milisekunde dok se ne applaya ostatak. Za analne
tipove dusu dalo ;)

[Ivan Popovski]

On 2010-06-11, Aleksandar Ivanisevic <aleks...@ivanisevic.de> wrote:
> commit je bitan da bi promjena koja obuhvaca vise od jednog rulea bila
> applayana atomicno, jerbo jedan rule kao takav moze znacit otvoren
> firewall za one 3 milisekunde dok se ne applaya ostatak. Za analne
> tipove dusu dalo ;)

To uopce nije upitno. Na visekorisnickom sustavu u jednom dijelu stvar mora biti
atomicna (u idealnom slucaju bi bila acid lol), samo sto se meni estetski ne
svidja ideja da se konkretno to cudo programira kao baza (mogli su to napraviti
nize). To je cisto osobna preferneca posto mi je svakodnevno koristenje znanosti
o bazama iritantno i dosadno (proporcinalno potraznji na trzistu :-).

[Drazen Kacar]

Aleksandar Ivanisevic wrote:
> Ivan Popovski <ip@nj.g> writes:
>
> > On 2010-06-11, Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> >> Ja ne vidim zasto se za iptables ne bi mogao napisati programcic koji bi
> >> parsirao file s citljivijim pravilima, a onda to pretvorio u necitljive
> >> iptables inkantacije. I obratno. Pretpostavljam da nikoga nije dovoljno
> >> svrbilo.
> >
> > Moja pretpostavka je zato sto su developeri u jednom trenu zabrijali da bi se
> > lib trebao ponasati kao baza. Pazi imas cak i commit :-)
>
> commit je bitan da bi promjena koja obuhvaca vise od jednog rulea bila
> applayana atomicno, jerbo jedan rule kao takav moze znacit otvoren
> firewall za one 3 milisekunde dok se ne applaya ostatak. Za analne
> tipove dusu dalo ;)

Uglavnom se commit implementira za situacije kad ti prvi rule isključuje
konekciju pomoću koje administriraš stroj, a drugi ju uključuje. Ali i na
analne tipove treba misliti. To je jedan nezanemarivi dio klijentele. :-)

[Davorin Vlahovic]

[Fri, 11 Jun 2010 11:08:43 +0000 (UTC)] Drazen Kacar je napisao/la:
> Vjerojatno nije, ali za file systeme u kernelima postoji API (koji obično
> nije stabilan preko releasova) zato što je file systema puno i API je
> pametno i poželjno imati. Pa ti je onda portanje puno jednostavnije jer
> veliku većinu koda u file systemu ne moraš ni pogledati.
>
> Firewall je, s druge strane, nešto što pušta pipke posvuda po networking
> kodu, a API-ja obično nema jer je firewall jedina stvar s takvim
> potrebama, pa je pravljenje nekakvog nivoa apstrakcije između njega i
> networking koda gubitak vremena i energije.

I koji bi problem bio da se firewall usteka negdje izmedu primanja i slanja
raw paketa? Koliko ja vidim, uklopiti firewall u tcp/ip stack je jedna od
jednostavnijih stvari :)

[Drazen Kacar]

Davorin Vlahovic wrote:

> I koji bi problem bio da se firewall usteka negdje izmedu primanja i slanja
> raw paketa? Koliko ja vidim, uklopiti firewall u tcp/ip stack je jedna od
> jednostavnijih stvari :)

Ne znam. Trebao bih imati iskustva s pisanjem firewalla da bih mogao
odgovoriti na to pitanje. Mogu samo reći da mi postano objašnjenje djeluje
uvjerljivo. Vrag je u detaljima, a kad ih ima previše, sažetak izgleda
onako kako je napisano.

[Davorin Vlahovic]

[Fri, 11 Jun 2010 17:16:43 +0000 (UTC)] Drazen Kacar je napisao/la:
> Davorin Vlahovic wrote:
>
>> I koji bi problem bio da se firewall usteka negdje izmedu primanja i slanja
>> raw paketa? Koliko ja vidim, uklopiti firewall u tcp/ip stack je jedna od
>> jednostavnijih stvari :)
>
> Ne znam. Trebao bih imati iskustva s pisanjem firewalla da bih mogao
> odgovoriti na to pitanje. Mogu samo reći da mi postano objašnjenje djeluje
> uvjerljivo. Vrag je u detaljima, a kad ih ima previše, sažetak izgleda
> onako kako je napisano.

Shvacam, ali za packet filter ne moras razgovarati sa sto ja znam kakvim
slojevima poput VFS-a s jedne strane ili drivera s druge strane; jednostavno
se ukopcas umjesto/ispred/iza queuea za odlazne i dolazne pakete i miran si.

[Josip Almasi]

Ivan Popovski wrote:
>
> Moja pretpostavka je zato sto su developeri u jednom trenu zabrijali da bi se
> lib trebao ponasati kao baza. Pazi imas cak i commit :-)

A jel ima rollback?:)

IMHO nema to veze s bazama.
Bitno je da se cijeli rule chain moze promijenit odjednom, ako radis na
zivom sistemu sa puno prometa.

Pozdrav...