[ pisac @ 10.11.2014. 15:29 ] @
iptables -t nat -A PREROUTING -i $EXT -p udp --dport 6060 -j REDIRECT --to-ports 5060
Prestalo da radi!

Odjednom je prestalo da radi gore navedeno natovanje (tj. patovanje). Modul se učita, ali ovo pravilo ne radi. Nisam uspeo to da rešim, pa sam promenio port na samom servisu i prilagodio firewall.

Slekver je u pitanju, kernel 2.6.24.5-smp

Međutim, imam veći problem. I druga natovanja prave probleme, recimo ovo "ne hvata":
iptables -t nat -A POSTROUTING -s $SPOLJNI_IP -d $UDALJENA_MREZA -j SNAT --to-source $UNUTRASNJI_IP
a to isto samo kada izbacim sors, hvata:
iptables -t nat -A POSTROUTING -d $UDALJENA_MREZA -j SNAT --to-source $UNUTRASNJI_IP

Takođe, server ima neke žute minute u kojima recimo počne da "ne hvata" i FORWARD tabela, tako da počne da preskače (loguje i dropuje) forward pakete za koje ima definisano pravilo da ih prosledjuje, a onda to sve odjednom prestane i nastavi da radi normalno.

Dakle, iptables je bolestan, kako bi se reklo. I to se razboleo bez razloga: ništa nisam instalirao niti menjao, jednostavno je pre neki mesec počeo da boluje. Sve to sa identičnim pravilima radi na drugim serverima.

E, sad, mala istorija tog servera: koliko vidim, ja sam nekada davno kompajlirao tu neki kernel, budžio nešto i eksperimentisao. Međutim, posle sam to vratio na staro tako što sam vratio "fabrički" kernel, ali nešto i dalje nije ferceralo kako treba. Pa sam pregazio instalaciju sa originalnom, i tu je kao nešto bolje počelo da radi (tj. većina stvari). Sve u svemu, nikad nije 100% počelo da radi kao kad je bio glanc fabrički, ali svejedno dovoljno dobro je radilo godinama sve dok nije puklo to natovanje.

Pitanje je u stvari za nekog pravog poznavaoca ... šta tu u sistemu može biti što ovako za*ebava, i kako ga 'opraviti?
[ vladared @ 12.11.2014. 09:16 ] @
Možda prvo da kažeš šta si hteo da uradiš? Isto tako ako ti ne valja skripta, onda je potrebna čitava skripta sa istim objašnjenjem šta si želeo da uradiš. Ovako odokativno mi nije jasno šta si hteo sa onim -d ? Standardano natovanje SNATom izgleda ovako iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -j SNAT --to-source 200.119.78.110
[ pisac @ 12.11.2014. 12:22 ] @
Mogu ja da objasnim ali to je skretanje teme na nebitno. Skripta valja, neke komande ne rade ni kada su same u celoj konfiguraciji. To što te buni jeste SNAT-ovanje za IPSEC tunel preko Interneta da bi adresa koja stigne tamo bila lokalna a ne javna. I to radi na drugim kompjuterima.

Suština je da ne radi ovo (što je jasno samo po sebi):
iptables -t nat -A PREROUTING -i $EXT -p udp --dport 6060 -j REDIRECT --to-ports 5060
[ vladared @ 12.11.2014. 14:27 ] @
Mene što buni je što ti ne radi i sa generičkim kernelom. Generalno za natovanje je potrebno u kernelu da je uključeno CONFIG_IP_NF_IPTABLES da bi radilo i to bi bilo uredu da si ostao na custom kernelu. Ovaj problem sa redirektovanjem porta bi imao smisla ako je "virtualna mreža" a ne fizička tipa eth0:0 . Bio je bug, valjda je sada razrešen, baš sa nat-ovanjem, ako na isrom računaru imaš ipv6 i ipv4 istovremeno dignute interfejse...
[ Aleksandar Đokić @ 12.11.2014. 20:42 ] @
Inace,

Citat:
da bi adresa koja stigne tamo bila lokalna a ne javna


to bi trebalo da se radi tako sto iz nata izostavis opseg koji "ide" preko tunela, a ne natujes na javnu pa opet na 1918.
[ pisac @ 12.11.2014. 21:40 ] @
Ne natuje se dvaput, adresa servera je javna kada ide kroz tunel IPSEC-a jer uzima adresu spoljnog interfejsa preko koga ide, mora se natovati.
[ Aleksandar Đokić @ 12.11.2014. 22:42 ] @
Tunel "drze" javne, a saobracaj koji ide kroz tunel (koji definises u IPSec polisi) ne treba da se natuje tj. sve sto za "dst" ima mrezu koja je sa druge strane tunela ne treba da ide na "masquarade".

Jedino ako se nesto ne razumemo.


[ pisac @ 12.11.2014. 23:43 ] @
Pa ne razumemo se. Kada se sa servera šalje kroz tunel onda mora da se natuje, a sa mreže ne mora.
[ Aleksandar Đokić @ 13.11.2014. 07:09 ] @
Ok, meni je u glavi da saljes sa mreze.

A rekao si da radi logovanje, a redirekt nece? Nad istim pravilom? Ako je tako ja bih rekao da je bug.
[ pisac @ 15.11.2014. 03:44 ] @
Eh, imam problem i na drugom kompjuteru. Ono što naveh u prvom postu:
iptables -t nat -A POSTROUTING -s $SPOLJNI_IP -d $UDALJENA_MREZA -j SNAT --to-source $UNUTRASNJI_IP

Se sada komplikuje: Delimično radi na "bolesnom" tako što natuje na pravu adresu ali pri tome i promeni port pa umesto 5060 ili (drugi servis) 4569 na cilji stiže 1199 (za oba servisa), a onda još čudnije, i udaljeni server na kome je sve bilo u redu, kada šalje na ovaj prvi umesto 5060 promeni port na 1063. Još čudnije je da sa trećim serverom sve funkcioniše kako treba u odnosu na prvi (bolesni) server (koji dakle prema trećem serveru ne menja port), a u odnosu na drugi isto ima problema.

Takođe me zbunjuje da između prvog i drugog kompjutera ne radi ping na početku, sve dok ne ostavim pingovanje preko minut ili nešto tome slično, a onda proradi. I prvi i drugi kompjuter šalju ping kako treba (sa natovanom adresom) ali onaj koji odgovara na ping ne koristi natovanje već šalje sa javne adrese (tako rade sve dok ne prođe neko vreme upornog pingovanja, i onda odjednom prorade). A pri tome sa trećim serverom sve radi uvek (sa istim pravilima).

drugi i treći server imaju isti kernel: 2.6.21.5, samo što treći server nije "smp".

E sad mi ništa nije jasno.
[ pisac @ 17.11.2014. 01:39 ] @
Hajde neko da mi da ideju zašto bi server 1 koji drži port 5060, prilikom slanja ka drugom serveru preko SNAT-a menjao port u 1064 a ka trećem serveru u 1065. Dakle u pitanju je onaj server koji nije bolestan, ovde je sve radilo kako treba dok nisam uveo IPSEC i SNATovanje.

Dakle potpuno identično SNAT pravilo na jednom serveru radi kako treba a na drugom proizvodi ovakav čudan efekat.

Gde u logovima mogu da iskopam konkretne razloge za konkretnu promenu porta. Pratim conntrack tabelu ali od nje nema vajde jer samo vidim šta se desilo ali ne i zašto se to desilo. Davim se ovde u čitanju svega što mogu da nađem o iptables/conntrack ali za sada nisam našao nikakav odgovor.
[ vladared @ 17.11.2014. 06:58 ] @
@pisac
i dalje me buni šta hoćeš da uradiš. Ja bih recimo uze i prvo u prerutingu odradio dnat, pa tek onda u postroutingu snat. Ovako mi deluje da si sve na jednom mestu hteo da zguraš. Koliko ja razumem, želiš da svi "korisnici" u tvojoj lokalnoj mreži imaju neki sourceip neki port a u stvarnosti da gađaju neki externiip neki port?

iptables -t nat -A PREROUTING -p tcp -s 0/0 -d sourceip --dport 5060 -j DNAT --to externiip:1063
iptables -t nat -A POSTROUTING -o eth0 -d externiip -j SNAT --to-source sourceip

ovako radiš da tvoji korisnici idu (npr) sourceip:5060, a u stvarnosti gađaju externiip:1063 ili recimo ako staviš da je source ip192.168.1.5 i recimo port 8080 a externi ip recimo googleov 216.239.59.105:80 tvoji korisnici kada bi ukucali http://192.168.1.5:8080 bi dobijali googleov interfejs.
[ pisac @ 17.11.2014. 11:14 ] @
Ne menjam ništa za mrežu, ona prirodno ima svoje adrese koje rade kako treba. Problem su samo serveri/gejtveji koji održavaju IPSEC vezu među mrežama, jer oni imaju dve adrese: unutrašnju i spoljnu. Pošto se sa drugim serverima/gejtvejima i sa drugim kompjuterima u drugim mrežama preko IPSECa povezuju preko spoljnog interfejsa onda automatski uzimaju spoljnu adresu, e ta adresa mora da se promeni da bude unutrašnja kako bi veza radila.

U ovom prethodno pomenutom slučaju, kada se uradi SNAT server menja i port a ne samo ip adresu, a to mi pravi probleme. Konkretno, treći server pristupa drugom serveru 10.0.2.1:5060, a dobija odgovor sa 10.0.2.1:1065 jer je drugi server poslao odgovor sa (adresa samo kao primer 194.106.162.2:5060 ali je tokom SNAT-ovanja to promenjeno u 10.0.2.1:1065 (a trebalo je da bude promenjeno u 10.0.2.1:5060).
[ niceness @ 17.11.2014. 21:00 ] @
Nisam detaljno čitao temu pa neću ulaziti u ostalo, ali što se tiče SNAT i promene porta jel misliš SNAT menja source port paketa?
To je normalno, tako radi SNAT, ukoliko je moguće source port će ostati isti ali nema garancije (pogledaj opis u man stranici iptables-extensions).
[ pisac @ 17.11.2014. 21:17 ] @
Utvrdio sam danas da li će se desiti promena porta zavisi od toga kojim redosledom se uspostavljaju veze nakon startovanja prazne conntrack tabele. Kada ugasim nat/firewall i pobrisem sve ipt module, pa startujem nat/firewall, uspostavljanje veza kreće ispočetka, i onda nekada u nekom redosledu sve radi kako treba, a u nekom drugom redosledu počne da menja port kada SNAT-uje. Izgleda da mu smeta što postoji već servis na portu 10.0.2.1:5060 koji je uspostavio vezu sa nekim pa ne može da uradi i SNAT na tu istu adresu:port ka nekom drugom klijentu. Ali tu pretpostavku treba još da proverim.

Međutim, ono što me (i dalje) buni je da u nekom redosledu uspostavljanja veza, može da se desi da odlazni paketi sa javne adrese i dotičnog porta uopšte više ne prolaze kroz SNAT pravilo već ono biva potpuno ignorisano, i paketi jednostavno ne stižu kroz IPSEC tunel. Znači ne stižu nikakvi, čak ni bar promenjeni na pogrešan port. E to ne kapiram nikako.

Nego, sada se javlja pitanje: kako napraviti ono što mi treba, a da funkcioniše kako treba? Dakle server koji radi IPSEC vezu je ujedno i server koji koristi 5060 port na obe svoje adrese, a potrebno je da kada šalje kroz ipsec tunel (koji je preko javne adrese) koristi svoju internu adresu a ne spoljnu.
[ niceness @ 18.11.2014. 00:12 ] @
Citat:
pisac: Utvrdio sam danas da li će se desiti promena porta zavisi od toga kojim redosledom se uspostavljaju veze nakon startovanja prazne conntrack tabele. Kada ugasim nat/firewall i pobrisem sve ipt module, pa startujem nat/firewall, uspostavljanje veza kreće ispočetka, i onda nekada u nekom redosledu sve radi kako treba, a u nekom drugom redosledu počne da menja port kada SNAT-uje. Izgleda da mu smeta što postoji već servis na portu 10.0.2.1:5060 koji je uspostavio vezu sa nekim pa ne može da uradi i SNAT na tu istu adresu:port ka nekom drugom klijentu. Ali tu pretpostavku treba još da proverim.

Upravo se to dešava.

Citat:
Međutim, ono što me (i dalje) buni je da u nekom redosledu uspostavljanja veza, može da se desi da odlazni paketi sa javne adrese i dotičnog porta uopšte više ne prolaze kroz SNAT pravilo već ono biva potpuno ignorisano, i paketi jednostavno ne stižu kroz IPSEC tunel. Znači ne stižu nikakvi, čak ni bar promenjeni na pogrešan port. E to ne kapiram nikako.

Nego, sada se javlja pitanje: kako napraviti ono što mi treba, a da funkcioniše kako treba? Dakle server koji radi IPSEC vezu je ujedno i server koji koristi 5060 port na obe svoje adrese, a potrebno je da kada šalje kroz ipsec tunel (koji je preko javne adrese) koristi svoju internu adresu a ne spoljnu.

Može li malo više detalja, routing tabela (ip route sh), ip adrese na interfejsima (ip addr sh) (promeni javnu), adresa udaljene mreže preko ipsec itd.
I koja je aplikacija u pitanju - Asterisk?
[ pisac @ 18.11.2014. 01:02 ] @
Jeste Asterisk. Ali, evo najzad uzroka, a i rešenja:

Dakle, problem je izazivalo ponašanje SNAT-a i CONNTRACK tabele, koje se sastoji u sledećem:

- CONNTRACK pamti ko je kome prvi pristupio, da li udaljeni klijent/server lokalnom serveru, ili obrnuto
- Ukoliko je udaljeni klijent/server (bilo koji od postojećih) prvi pristupio lokalnom serveru na 10.0.2.1:5060, to se upiše u tabelu i to ostaje tako zauvek (tj. dok ne istekne taj zapis, ali ako udaljeni klijent/server stalno ponavlja zahtev onda taj zapis nikada ne ističe).
- Kada lokalni server pokuša da pošalje zahtev bilo kom udaljenom klijentu/serveru preko 10.0.2.1:5060, ukoliko u CONNTRACK tabeli postoji zapis da je neki (bilo koji) udaljeni već pristupao toj adresi:portu, onda SNAT jednostavno promeni port za odlazni saobraćaj! Znači, čak i kada lokalni server odgovara onom istom udaljenom koji je probao da pristupi portu 5060 i čiji se zapis nalazi u CONNTRACK, SNAT to promeni i lokalni server odgovara preko recimo porta 1024. I to ostaje tako zabetonirano jer zapisi ne ističu pošto se zahtevi stalno obnavljaju. Možda je uzrok ovakvom blesavom ponašanju SNAT-a taj što je udaljeni u stvari pristupio realnoj lokalnoj adresi a ne preko nekih DNATova, pa SNAT ta dva saobraćaja ne povezuje i tu nastaje zbun
- Međutim, čak ni ovo nije neki problem, veza opet može da radi. Problem je ako je i udaljeni server (u ovom slučaju samo server jer klijent nema taj problem) pristupio sa pogrešnog porta pošto je i njemu zbog SNAT pravila promenjen odlazni port (isti problem kao lokalni server), pa on recimo pristupi sa 1032 na lokalni 5060, a ovaj lokalni odgovara sa 1024 na udaljeni 5060 (pošto je konfiguraciji navedeno da je to broj porta udaljenog servera), onda se veza ne uspostavlja, i to ostaje tako dok god ti zapisi ne isteknu iz CONNTRACK tabela a to se ne dešava nikad pošto oba servera stalno ponavljaju zahteve.

Sve to se ne dešava ako lokalni server prvi pokuša da pristupi udaljenom, jer onda se u CONNTRACK tabeli upisuje da je probao da pristupi sa 5060 (tj. zauzeo je taj port) i to ostaje tako zabetonirano dok god taj zapis ne istekne iz CONNTRACK tabele a to se jelte ne dešava dok god server radi.

Eto uzroka, a šta bi bilo rešenje?

Pa prvo što mi je palo napamet izgleda i da radi. Proveriću ovih dana da li ima nekih negativnih posledica po neke druge stvari, ali za sada radi sledeće:

iptables -t raw -I PREROUTING -i $ext_iface -d $local_ip -j NOTRACK


U suštini to govori da CONNTRACK jednostavno ne pamti ništa što mu sa spoljneg interfejsa stiže na lokalnu adresu, tako da onda i nema tih zapisa koji prave problem za SNAT

Ah, da, zaboravih: nisam provalio zašto se nekada dešavalo da paketi jednostavno uporno ignorišu SNAT, ali koliko sam video moguće je da je uzrok tome što se odlazni zapis u CONNTRACK tabeli formira pre nego što se upostavi SNAT pravilo (tj. pre potpunog podizanja firewall-a) i onda SNAT jednostavno nastavi da ignoriše identične pakete koji odgovaraju tom CONNTRACK zapisu. Mrzelo me je da to proveravam više puta, ali sam u par navrata uočio da čim taj loš zapis nestane iz CONNTRACK tabele (zaustavim server dok ne istekne), posle toga nadalje sve radi preko SNAT-a.

[Ovu poruku je menjao pisac dana 18.11.2014. u 02:14 GMT+1]
[ niceness @ 18.11.2014. 09:23 ] @
To si ga baš izanalizirao :D
U suštini već si našao workaround, ali kad smo već na temi...

Za routing tabelu sam pitao pošto se ovo možda može uraditi bez NAT-a.
Ovde je glavni problem što asterisku ne možeš reći sa kog source interfejsa da šalje pakete (ako sluša na više interfejsa) već on sam odluči na osnovu odredišne adrese i valjda routing tabele. Malo sam potražio kako bi se trebao ponašati u ovakvoj sitaciju ali nisam uspeo naći jasan odogovor, ako neko zna neka napiše. Mislim da ukoliko na serveru postoji ruta za udaljenu mrežu u routing tabeli sa definisanom source adresom asterisk bi trebao slati pakete prema toj mreži sa te source adrese.

Dođe mi da napravim sličnu mrežu tvojoj i probam :) Inače ja koristim freeswitch (isto b2bua kao asterisk), ali tamo je drugačije. Za svaku ipadresu:port na koju se binduje definiše se poseban sip profil koji se onda koristi u dialplanu itd. pa se ima kontrola sa koga intefejsa se uspostavlja veza.

Citat:
Ah, da, zaboravih: nisam provalio zašto se nekada dešavalo da paketi jednostavno uporno ignorišu SNAT, ali koliko sam video moguće je da je uzrok tome što se odlazni zapis u CONNTRACK tabeli formira pre nego što se upostavi SNAT pravilo (tj. pre potpunog podizanja firewall-a) i onda SNAT jednostavno nastavi da ignoriše identične pakete koji odgovaraju tom CONNTRACK zapisu. Mrzelo me je da to proveravam više puta, ali sam u par navrata uočio da čim taj loš zapis nestane iz CONNTRACK tabele (zaustavim server dok ne istekne), posle toga nadalje sve radi preko SNAT-a.

Moguće je, samo zašto si morao čekati da zapis nestane, možeš ih brisati jedan po jedan ili flush-ovati celu tabelu?
[ pisac @ 18.11.2014. 09:44 ] @
Ne znam kako to da uradim. Probao sam da nađem conntrack, conntrack-tool ili neki sličan bin ali ne nađoh to na slekveru.
[ niceness @ 18.11.2014. 10:18 ] @
Jedino da instaliraš conntrack-tools iz source-a, samo zavisi od nekoliko biblioteka pa ćeš možda morati i njih ako ih već nema.
[ pisac @ 18.11.2014. 22:27 ] @
Ovo manje više radi, ali nije rešilo sve probleme. Ping se i dlje ponaša kao što sam ranije naveo:
Citat:
Takođe me zbunjuje da između prvog i drugog kompjutera ne radi ping na početku, sve dok ne ostavim pingovanje preko minut ili nešto tome slično, a onda proradi. I prvi i drugi kompjuter šalju ping kako treba (sa natovanom adresom) ali onaj koji odgovara na ping ne koristi natovanje već šalje sa javne adrese (tako rade sve dok ne prođe neko vreme upornog pingovanja, i onda odjednom prorade). A pri tome sa trećim serverom sve radi uvek (sa istim pravilima).


Znači, server1 pinguje server2 sa lokalne adrese (kako treba) a server2 odgovara sa javne sve do nekog trenutka kada mu nešto cakne i nastavi da odgovra sa lokalne. Samo po sebi to ne bi bilo mnogo značajno, ali ipak ima i neke posledice: ssh se slično ponaša, treba "probiti" vezu da bi proradilo.

Sve sam gledao, i conntrack tabelu, i detaljne NAT logove, i nema apsolutno ničega što se menja u tom trenutku prelaska. Baš ništa. Napravio sam specijalno firewall/nat sa logovanjem svake i najmanje sitnice, i najčudnije u svemu tome je što se nat tabela uopšte ne aktivira tokom odgovaranja na ping, ni u prvom ni u drugom slučaju. Niti se brojači uvećavaju.

Evo dva uzastopna pinga u trenutku kada je promenjena adresa sa javne na privatnu (pingovi su bili na 0.2 sekunde, zato su u istoj sekundi):

Nov 18 18:13:29 hetis kernel: [PRE/mangle-FALL] IN=ppp72 OUT= MAC= SRC=$PRVI_SERVER_JAVNI_IP DST=$DRUGI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=ESP SPI=0x72cc81d
Nov 18 18:13:29 hetis kernel: [IN/mangle-FALL] IN=ppp72 OUT= MAC= SRC=$PRVI_SERVER_JAVNI_IP DST=$DRUGI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=ESP SPI=0x72cc81d
Nov 18 18:13:29 hetis kernel: [IN/filter 50/ACCEPT] IN=ppp72 OUT= MAC= SRC=$PRVI_SERVER_JAVNI_IP DST=$DRUGI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=ESP SPI=0x72cc81d
Nov 18 18:13:29 hetis kernel: [PRE/raw NOTRACK] IN=ppp72 OUT= MAC= SRC=10.0.1.1 DST=10.0.2.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41043 SEQ=190
Nov 18 18:13:29 hetis kernel: [PRE/mangle ipsec/ACCEPT] IN=ppp72 OUT= MAC= SRC=10.0.1.1 DST=10.0.2.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41043 SEQ=190
Nov 18 18:13:29 hetis kernel: [IN/mangle ipsec/ACCEPT] IN=ppp72 OUT= MAC= SRC=10.0.1.1 DST=10.0.2.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41043 SEQ=190
Nov 18 18:13:29 hetis kernel: [IN/filter ipsec/ACCEPT] IN=ppp72 OUT= MAC= SRC=10.0.1.1 DST=10.0.2.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41043 SEQ=190
Nov 18 18:13:29 hetis kernel: [OUT/mangle ipsec/ACCEPT] IN= OUT=ppp72 SRC=$DRUGI_SERVER_JAVNI_IP DST=10.0.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28611 PROTO=ICMP TYPE=0 CODE=0 ID=41043 SEQ=190
Nov 18 18:13:29 hetis kernel: [OUT/filter ipsec/ACCEPT] IN= OUT=ppp72 SRC=$DRUGI_SERVER_JAVNI_IP DST=10.0.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28611 PROTO=ICMP TYPE=0 CODE=0 ID=41043 SEQ=190
Nov 18 18:13:29 hetis kernel: [POST/mangle ipsec/ACCEPT] IN= OUT=ppp72 SRC=$DRUGI_SERVER_JAVNI_IP DST=10.0.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28611 PROTO=ICMP TYPE=0 CODE=0 ID=41043 SEQ=190
Nov 18 18:13:29 hetis kernel: [OUT/mangle-FALL] IN= OUT=ppp72 SRC=$DRUGI_SERVER_JAVNI_IP DST=$PRVI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=28612 PROTO=ESP SPI=0x8bec27d
Nov 18 18:13:29 hetis kernel: [OUT/filter-FALL] IN= OUT=ppp72 SRC=$DRUGI_SERVER_JAVNI_IP DST=$PRVI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=28612 PROTO=ESP SPI=0x8bec27d
Nov 18 18:13:29 hetis kernel: [POST/mangle-FALL] IN= OUT=ppp72 SRC=$DRUGI_SERVER_JAVNI_IP DST=$PRVI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=28612 PROTO=ESP SPI=0x8bec27d

Nov 18 18:13:29 hetis kernel: [PRE/mangle-FALL] IN=ppp72 OUT= MAC= SRC=$PRVI_SERVER_JAVNI_IP DST=$DRUGI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=54 ID=68 DF PROTO=ESP SPI=0x72cc81d
Nov 18 18:13:29 hetis kernel: [IN/mangle-FALL] IN=ppp72 OUT= MAC= SRC=$PRVI_SERVER_JAVNI_IP DST=$DRUGI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=54 ID=68 DF PROTO=ESP SPI=0x72cc81d
Nov 18 18:13:29 hetis kernel: [IN/filter 50/ACCEPT] IN=ppp72 OUT= MAC= SRC=$PRVI_SERVER_JAVNI_IP DST=$DRUGI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=54 ID=68 DF PROTO=ESP SPI=0x72cc81d
Nov 18 18:13:29 hetis kernel: [PRE/raw NOTRACK] IN=ppp72 OUT= MAC= SRC=10.0.1.1 DST=10.0.2.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41043 SEQ=191
Nov 18 18:13:29 hetis kernel: [PRE/mangle ipsec/ACCEPT] IN=ppp72 OUT= MAC= SRC=10.0.1.1 DST=10.0.2.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41043 SEQ=191
Nov 18 18:13:29 hetis kernel: [IN/mangle ipsec/ACCEPT] IN=ppp72 OUT= MAC= SRC=10.0.1.1 DST=10.0.2.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41043 SEQ=191
Nov 18 18:13:29 hetis kernel: [IN/filter ipsec/ACCEPT] IN=ppp72 OUT= MAC= SRC=10.0.1.1 DST=10.0.2.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41043 SEQ=191
Nov 18 18:13:29 hetis kernel: [OUT/mangle ipsec/ACCEPT] IN= OUT=ppp72 SRC=10.0.2.1 DST=10.0.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=13399 PROTO=ICMP TYPE=0 CODE=0 ID=41043 SEQ=191
Nov 18 18:13:29 hetis kernel: [OUT/filter ipsec/ACCEPT] IN= OUT=ppp72 SRC=10.0.2.1 DST=10.0.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=13399 PROTO=ICMP TYPE=0 CODE=0 ID=41043 SEQ=191
Nov 18 18:13:29 hetis kernel: [POST/mangle ipsec/ACCEPT] IN= OUT=ppp72 SRC=10.0.2.1 DST=10.0.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=13399 PROTO=ICMP TYPE=0 CODE=0 ID=41043 SEQ=191
Nov 18 18:13:29 hetis kernel: [OUT/mangle-FALL] IN= OUT=ppp72 SRC=$DRUGI_SERVER_JAVNI_IP DST=$PRVI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=28613 PROTO=ESP SPI=0x8bec27d
Nov 18 18:13:29 hetis kernel: [OUT/filter-FALL] IN= OUT=ppp72 SRC=$DRUGI_SERVER_JAVNI_IP DST=$PRVI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=28613 PROTO=ESP SPI=0x8bec27d
Nov 18 18:13:29 hetis kernel: [POST/mangle-FALL] IN= OUT=ppp72 SRC=$DRUGI_SERVER_JAVNI_IP DST=$PRVI_SERVER_JAVNI_IP LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=28613 PROTO=ESP SPI=0x8bec27d


[Ovu poruku je menjao pisac dana 19.11.2014. u 13:01 GMT+1]
[ pisac @ 19.11.2014. 11:28 ] @
Da objasnim log:

- IPSEC/ESP prvo ulazi i prolazi kroz firewall do 50/ACCEPT, a onda ga sistem dešifruje i ponovo šalje na početak (glup način koji koristi kernel 2.6+, mnogo bi bilo bolje da radi sa posebnim ipsec interfejsom kao na 2.4). To su prva tri zapisa u pasusu.
- Prvo pravilo koje dešifrovani ping hvata na ulazu je lanac PREROUTING tabela raw, NOTRACK.
- Posle toga slede pravila koja jednostavno propuštaju ipsec označene pakete, da se na njih ne bi primenilo neko od pravila koja važe za ostali saobraćaj sa spoljneg ppp interfejsa (jedna od osobina koje me nerviraju na kernelu 2.6+, da je ponašanje kao na 2.4 gde ipsec paketi dolaze sa posebnog interfejsa, za time ne bi bilo potrebe)
- Posle izlaza preko spoljnog interfejsa (lanac POSTROUTING tabela mangle) ping paketi koji su upućeni na mrežu zaštićenu ipsecom se opet vraćaju u sistem radi šifrovanja, i ponovo propuštaju ka izlazu (opet taj glup sistem na 2.6+ kernelima). To su zadnja tri zapisa u pasusu.

Vidi se da se nat tablela nigde ne dotiče, ni na ulazu ni na izlazu.

U drugom pasusu je sledeći ping koji je počeo da odgovara sa lokalne adrese a ne javne. Vidi se da je apsolutno sve isto, da se takođe ne dotiče nikakvo nat pravilo. Tako da ne vidim ni uzrok ni rešenje za ovakvo ponašanje.

Čini mi se da je glavni uzrok ovakvog uvrnutog ponašanja taj što se paketi vrte u petlji dešifrovanja i šifrovanja kroz iste iptables lance i isti interfejs. Ako ne nađem uzrok/rešenje, mislim da ću morati da batalim ovaj 2.6 ipsec i da probam da nabudžim ono rešenje sa 2.4 kernela, ili da eventualno nešto smislim sa tun/tap interfejsima što bi ih šifrovalo pomoću ipseca. Time što bih dobio poseban interfejs za ipsec saobraćaj bih verovatno rešio sve navedene probleme zbog kojih gubim ovde nedelje.