Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

IPSEC na kernelu 2.6

[es] :: Linux mreže :: IPSEC na kernelu 2.6

[ Pregleda: 5427 | Odgovora: 1 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

pisac

Član broj: 13046
Poruke: 4578



+3341 Profil

icon IPSEC na kernelu 2.608.11.2014. u 22:47 - pre 114 meseci
Imam problem sa NAT-om za IPSEC tunel: ne želim da mi SNAT-uje adrese iz unutrašnje mreže kada ih šalje kroz tunel.

Dakle, IPSEC tunel preko Interneta sam uspostavio (kriptovan je samo tunel, spoljne adrese oba hosta nisu vezane IPSEC-om), pri tome sam koristio samo setkey i eventualno racoon (radi i bez njega, ručnim unošenjem u setkey), rute odradi sam kernel (mada se ne vide u ruting tabeli). Postavio sam NAT pravilo koje SNAT-uje unutrašnjom adresom linux rutera sve što se šalje kroz tunel na drugi host, i sve to radi.

iptables -t nat -I POSTROUTING -d 10.0.2.0/24 -j SNAT --to-source 10.0.1.1


Međutim, rezultat ovoga je da svaki kompjuter iz mreže 1 koji pristupa mreži 2 do tamo stiže pod adresom linux rutera koji drži tunel (10.0.1.1), što važi i u suprotnom smeru. To mi se ne sviđa. Mislio sam da je rešenje vrlo prosto, pa sam umesto gornjeg pravila postavio drugo:

iptables -t nat -I POSTROUTING -s $SPOLJNI_IP -d 10.0.2.0/24 -j SNAT --to-source 10.0.1.1


Pretvaranje spoljne adrese tog rutera u internu adresu bi služilo samo za slučajeve kada se baš sa tog linux rutera kontaktira udaljena mreža (preko interneta), dok sam za ostale (interne) adrese smatrao da nema potrebe za SNAT-ovanjem jer je tunel već uspostavljen među njima.

Međutim, tunel tada jednostavno ne radi. Tcpdump pokazuje da se ping šalje ali ne kroz tunel nego nazad na unutrašnji eternet interfejs kroz koji je ušao ping ali sa adresom spoljnog interfejsa!? Na drugoj strani ne stiže ništa. IPSEC jeste problematičan što se tiče tcpdumpa, ali kada tunel radi bar se vidi dolazni saobraćaj, dok se u ovom slučaju izmenjenog SNAT-a ne vidi ništa, tako da pretpostavljam da kroz tunel stvarno ništa i ne stiže.

primer: sa 10.0.1.50 pingujemo 10.0.2.60... tcpdump unutrašnjeg eterneta pokazuje otprilike:

ping 10.0.1.50 -> 10.0.2.60
ping $SPOLJNI_IP -> 10.0.2.60
ping $SPOLJNI_IP -> 10.0.2.60

(za svaki ulazni ping zaista se prikazuju dva pinga koji bi navodno trebalo da budu poslati kroz tunel ali su poslati nazad u unutrašnju mrežu, pa stoga nemaju kome da stignu niti ko može da odgovori na njih)

Zašto? Ne vidim razlog za takvo ponašanje, ja sam taj tunel između mreža posmatrao kao neku vrstu rutiranja koje radi kernel uz korišćenje IPSEC-a, s tim da se pravila rutiranja ne vide u ruting tabeli, međutim iz ovoga ispada da to ipak nije rutiranje već nešto drugo. Da je to obično rutiranje uz enkripciju, sve što se šalje sa mreže 10.0.1.0/24 bi trebalo da bude preko ruting tabele slato kroz tunel na mrežu 10.0.2.0/24 a odgovor iz druge mreže bi isto tako nalazio svoj put nazad kroz tunel, pa pretvaranje svih adresa iz mreže 10.0.1.0/24 u 10.0.1.1 ne bi bilo potebno. Tako sam ja to zamišljao, ali izgleda da nisam dobro zamišljao. Probao sam da dodam neke posebne rute baš za to što hoću, ali jednosavno nema efekta (paketi ne idu kroz tunel)

Dakle, zna li neko kako da nateram IPSEC tunel na kernelima 2.6+ da radi kao da je u pitanju obično rutiranje među mrežama?



[Ovu poruku je menjao pisac dana 09.11.2014. u 01:19 GMT+1]
 
Odgovor na temu

pisac

Član broj: 13046
Poruke: 4578



+3341 Profil

icon Re: IPSEC na kernelu 2.609.11.2014. u 10:57 - pre 114 meseci
Evo rešenja... još ga testiram ali koliko vidim to je to.

Dakle, problem je bilo pravilo...
iptables -t nat -A POSTROUTING -j MASQUERADE
...koje je natovalo sve što je poslato na internet a nisu ga uhvatila prethodna pravila.

E, sad, to nisam ukapirao ranije samo zato što se brojač paketa na tom pravilu iz nekog razloga ne uvećava tokom pingovanja koje sam ja radio, tako da ja nisam mogao da vidim gde nestaju paketi. Zašto se brojač ne uvećava, i zašto paketi idu u unutrašnju mrežu umesto spoljne, nije mi baš najjasnije, ali rešenje je sledeće:

Pošto se MASQUERADE ne može ukinuti iz opravdanih razloga, na Internetu sam našao da je rešenje postaviti pre njega:
iptables -t nat -I POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT

I to je to - radi (za sada, dok ne utvrdim eventualno neki drugi problem )
 
Odgovor na temu

[es] :: Linux mreže :: IPSEC na kernelu 2.6

[ Pregleda: 5427 | Odgovora: 1 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.