Dotaz: IPsec routování

[zipi]

Zdravím, rád bych požádal o pomoci ohledně IPsecového tunelu dle mého mám problém v routování jinak si to neumím vysvětlit nebo mi chybí nějaké pravidlo v iptables. Mam dva servery oba běží na CentOS 7 z komponentou libreswan.

Pobočka A 
má sítě 192.16.10.0/24,192.16.12.0/24 a 192.16.14.0/24

IPsec

type=tunnel
left=1.1.1.1
leftid=left=1.1.1.1
leftsubnet=192.16.0.0/16

right=2.2.2.2
right=left=2.2.2.2
rightsubnet=192.18.0.0/16

IPtables povolen forward
-A FORWARD -s 192.16.0.0/16 -d 192.18.0.0/16
-A FORWARD -s 192.18.0.0/16 -d 192.16.0.0/16

-A POSTROUTING -d 192.18.0.0/16 -j SNAT --to-source 192.16.10.1

Routa: pokud smažu mohu pingat ze serveru na druhy server i jakoukoliv adresu bez problému
ip route add 192.18.0.0/16 via 192.16.10.1 dev eth1

Pobočka B
má sítě 192.18.20.0/24, 192.18.22.0/24 a 192.18.24.0/24

IPsec
type=tunnel
leftid=2.2.2.2
leftid=left=2.2.2.2
leftsubnet=192.18.0.0/16

right=1.1.1.1
right=left=1.1.1.1
rightsubnet=192.16.0.0/16

IPtables povolen forward
-A FORWARD -s 192.18.0.0/16 -d 192.16.0.0/16
-A FORWARD -s 192.16.0.0/16 -d 192.18.0.0/16

-A POSTROUTING -d 192.16.0.0/16 -j SNAT --to-source 192.18.10.1

Routa: pokud smažu mohu pingat ze serveru na druhy server i jakoukoliv adresu bez problému
ip route add 192.16.0.0/16 via 192.18.10.1 dev eth1

Ze serveru A si bez problému mohu pingnout jakoukoliv ip adresu v pobočce B, ale jakmile se pokusím z nějaké stanice v pobočce A pingnout sít v B tak to neprojde .. Děkuji za pomoc.

---

---

Odpovědi

[Ignotus]

192.18.0.0/16 je preklep? Privátne siete sú v rozsahu 192.168.0.0/16

[SpaceExplo]

Na co ten SNAT a preco na 192.16.10.1? Co pojde do tunela uz mas definovane v leftsubnet a rightsubnet.

Podla man treba zrusit ten SNAT a pokial obe IPsec brany robia SNAT do internetu pre svoje lokalne siete, tak ho treba vylucit pre tunelovane siete:

server A

iptables -t nat -A POSTROUTING -s 192.16.0.0/16 -d 192.18.0.0/16 -j ACCEPT

server B

iptables -t nat -A POSTROUTING -s 192.18.0.0/16 -d 192.16.0.0/16 -j ACCEPT

[zipi]

Po dlouhé době opět otevírám tento problém .. Pokud se pokusím pingnout z jiného interface třeba eth1 "ping -I eth1 192.18.18.20" a kouknu se co to dělá pomocí tcpdumpu tak vidím, že linux se snaží celou tuhle komunikaci směřovat na veřejnou GW toho daného routeru. Pro představu "ARP, Request who-has 192.18.18.20 tell GW1, length 28". Co je zajímavé pokud se pokusím pingnout přes interface eth0 tak ping dorazí do místa určení.

[zipi]

Přejde mi to jako kdyby ignoroval pravidlo POSTROUTING.

[GeorgeWH]

A mas ho pred ostatnymi POSTROUTING pravidlami?

[zipi]

Ano, dokonce úplně jako první, ale nemělo by to mít nato vliv..

[Michal Kubeček]

Proč ne? Pravidla se vyhodnocují v pořadí, v jakém jsou v řetězci, a jakmile některé rozhodne, zbytek se nevyhodnocuje.

Možná bude ale problém v tom, že používáte tunnel mode, takže bude potřeba ošetřit (tj. povolit při filtraci a vyjmout z maškarády) jak vnitřní (192.16.x.x -- 192.18.x.x*), tak už zabalený (encapsulated, 1.1.1.1 -- 2.2.2.2) paket.

---

* - ty rozsahy byste si takhle vymýšlet neměl, dříve nebo později se budete potřebovat bavit s někým, kdo ty adresy skutečně má. Pokud vám nestačí rezervovaný rozsah 192.168.0.0/16, pořád jsou tu ještě 172.16.0.0/12 a 10.0.0.0/8.

[zipi]

Co použít místo tunnel mode ..? Tunnel mode mi přijde jako nejlepší možnost na propojení dvou síti, které jsou vzdálené od sebe x km .. Momentálně sítě jsou jedno jelikož to jsou testovací stroje zde bych nehledal chybu.

Poslední poznatek s testování ..

23:13:12.220184 IP 192.16.0.2 > 192.18.0.1: ICMP echo request, id 1, seq 1226, length 40
23:13:12.220308 IP Verejna IP > 192.18.0.1: ICMP echo request, id 1, seq 1226, length 40

[Michal Kubeček]

Co použít místo tunnel mode ..?

Nepsal jsem, že nemáte tunnel mode použít - nic jiného vám v podstatě ani nezbývá. Jen jsem upozorňoval, že když používáte tunnel mode, musíte počítat s tím, že potřebujete, aby netfilterem prošel jak vnitřní paket, tak ten vnější. (Viz např. tento diagram.)

Momentálně sítě jsou jedno jelikož to jsou testovací stroje zde bych nehledal chybu.

Na to se asi nejlépe hodí věta z klasického českého filmu "To neděláš dobře, Jaromíre, s těma sirkama." Ale dělejte jak myslíte…

Poslední poznatek s testování ..

To by odpovídalo tomu, že tomu paketu přeložíte zdrojovou adresu, takže už neodpovídá security policy a neaplikuje se ESP.

[zipi]

Tolik zbytečných slov a nic s toho .. Vyzkoušel jsem snad vše co mně napadlo i co zde padlo, ale výsledek je pořád stejný. Zaručeně bude problém v pravidlu na iptablesu. Jelikož to nefunguje pouze pokud přijde požadavek z eth1 zde nepomáhá ani ROUTA.

[Michal Kubeček]

Tolik zbytečných slov a nic s toho

Ta slova jsou zbytečná jen proto, že jste se je z nějakého důvodu rozhodl ignorovat.

Zaručeně bude problém v pravidlu na iptablesu.

…což se vám několik lidí (marně) snaží sdělit už od začátku.

[zipi]

Ach joo, místo toho, abych řešili problém, řešíme jestli tam bude ten subnet či jiný .. OK, ať se vyhneme debatě o ničem. Subnety jsem změnil na:

leftsubnet=10.16.0.0/16
rightsubnet=10.18.0.0/16

Samozřejmě poupravil vše potřebné, ale výsledek mám stejný. Tím pádem iptables vypadá takto:

IPtables povolen forward
-A FORWARD -s 10.18.0.0/16 -d 10.16.0.0/16
-A FORWARD -s 10.16.0.0/16 -d 10.18.0.0/16

-A POSTROUTING -d 10.16.0.0/16 -j SNAT --to-source 10.18.0.1 (GW na jedné straně)

Routa: pokud smažu mohu pingat ze serveru na druhy server i jakoukoliv adresu bez problému
ip route add 10.16.0.0/16 via 10.18.0.1 dev eth1

Zkoušel jsem i nastavit, že do internetu může vše kromě subnetu: 10.16.0.0/16

[Michal Kubeček]

Ty adresy jsou jen okrajový problém a jako takový jem to také prezentoval. Problém je v tom, že jste se rozhodl ignorovat ostatní rady.

Hned na začátku jste byl upozorněn, že ta maškaráda tam nemá co dělat, ale stále to ignorujete. (Tak, jak to máte napsané teď, by nejspíš až tak moc nevadila, ale z toho příkladu, který jste napsal 11.12. ve 23:17, jsem si celkem jistý, že to není jediné pravidlo v tabulce nat.)

Stejně tak jsem vám už dvakrát napsal, že netfilterem se bude zpracovávat jak původní paket, tak zatunelovaný, takže je potřeba povolit oboje, ale stále to ignorujete a máte tam pravidla jen pro ty vnitřní pakety. (Přesněji řečeno: pokud by ta pravidla vypadala tak, jak jste je napsal teď, nebudou mít vůbec žádný efekt, protože nemají žádnou akci.)

Místo toho, abyste rady, které jste dostal, vzal na vědomí a zkusil se podle nich zařídit, se do těch, kdo se vám snaží pomoci, začnete navážet. V takové situaci je opravdu těžké vám nějak pomoci a bylo by naivní, že to někoho bude bavit nějak přehnaně dlouho. Po pravdě řečeno, přehnaně dlouho už to bylo, takže pokud nezměníte svůj přístup, tento dotaz je pro mne vyřízený.

[bigBRAMBOR]

odeberu maskaradu, musi byt jeste pred pravidlem pro masq

iptables -t nat -I POSTROUTING -s 10.18.0.0/16 -o WAN -m policy --dir out --pol ipsec -j ACCEPT

a povolim routing, pouzivam staticke reqid, nechal jsem to tam

iptables -A FORWARD -s 10.18.0.0/16 -d 10.16.0.0/16 -i WAN -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.16.0.0/16 -d 10.18.0.0/16 -o WAN -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT

nic jineho na firewallu nemam a jedu

[zipi]

Tak problém vyřešen .. celou dobu jsme se točili okolo iptablesu, ale nikoho z nás nenapadlo se kouknout do /etc/sysctl.conf -> kde ještě chyběl jeden parametr..

Hele, mluv za sebe. Některým tady jejich ipsec vpnky fungují...

[Max]

Jinými slovy, neměl jsi povolený forwarde.
Asi to tady všichni brali jako samozřejmost.
Zdar Max

[NN]

Co znamena "tak to neprojde". Prijde paket ze stanice na router A? Odejde do tunelu? Dorazi na B? Odejde z B? Vrati se ze stanice? Odejde zpet do tunelu ... Pouzij laskave tcdpump/wireshark a dohledej si kde to hnije.