VPN routing probléma

 ( gelpg | 2013. január 2., szerda - 11:02 )

Sziasztok,

Egy OpenVPN routolással gyűlt meg a bajom, ebben kérnék segítséget. Egy site-to-site megoldás kell nekem annyi megkötéssel, hogy a site1 egy router mögött van, a router a megfelelő portot nat-olja, a site2-nek ide kellene belátnia. A kapcsolat felépül (mindkét oldalon látszik a logban), tun eszköz feljön a kért IP címmel, de nem tudom pingetni egymást.

Site1 vpn config
dev tun
ifconfig 10.20.2.1 10.20.2.2
up /etc/openvpn/office.up
secret /etc/openvpn/staticVPN.key
port 1194
user nobody
group nogroup
comp-lzo
persist-tun
persist-key
script-security 2
log /etc/openvpn/openvpn.log
verb 4

office up tartalma:
#!/bin/sh
route add -net 10.20.2.0 netmask 255.255.255.0 gw $5

Site 2 config
dev tun
remote x.x.x.x 1194
ifconfig 10.20.2.2 10.20.2.1
up /etc/openvpn/user/home.up
secret /etc/openvpn/user/staticVPN.key
user nobody
group nogroup
comp-lzo
script-security 2
log /etc/openvpn/user/openvpn.log
persist-tun
persist-key
verb 4

home.up tartalma:

#!/bin/sh
route add -net 10.20.2.0 netmask 255.255.255.0 gw $5
route add -net 192.168.1.0 netmask 255.255.255.0 gw $5

Site1 tűzfal:
minden lánc engedve
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * tun0 0.0.0.0/0 0.0.0.0/0
3 204 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0

Site 2 tűzfal
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 MASQUERADE all -- * tun0 0.0.0.0/0 0.0.0.0/0

INPUT és FORWARD láncok engedélyezve mindkét tun eszközre. A tcpdump site1-en jelzi, ha site2 felől pingetem, site2-re nem érkezik meg semmi. Ha bárkinek bármi javaslata/ötlete van, hogy hol szúrom el, az nagyon megköszönöm.

Üdv:
Péter

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

ip forward megvan? Többi jónak tűnik. Esetleg még: routeokat "push"-olni, shared secret helyett certek?

echo 1 > /proc/sys/net/ipv4/ip_forward

ip_forward bekapcsolva, ezt elfelejtettem írni. Ha cert-ekkel és felhasználónév-jelszó párossal csináltam, akkor valamiért az automatikus lefutás kiakadt ugyanazon alhalózati hibára hivatkozva. Lehet cert-ekkel nem felhasználónév-jelszó párossal is site-to-site-ot csinálni?

Elég a cert. De ez nem változtatna a lényegen. Route táblát kapunk, hátha ott van a kutya elásva?

Site 1

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.20.2.2 * 255.255.255.255 UH 0 0 0 tun0
10.20.2.0 10.20.2.2 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
default 192.168.1.2 0.0.0.0 UG 100 0 0 eth1

Site 2Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.20.2.1 * 255.255.255.255 UH 0 0 0 tun0
x.x.x.x * 255.255.255.252 U 0 0 0 eth0
10.20.2.0 10.20.2.1 255.255.255.0 UG 0 0 0 tun0
192.168.3.0 * 255.255.255.0 U 0 0 0 eth1
192.168.1.0 10.20.2.1 255.255.255.0 UG 0 0 0 tun0
192.168.9.0 * 255.255.255.0 U 0 0 0 eth2
default y.y.y.y 0.0.0.0 UG 0 0 0 eth0

x-ek és y-ok helyén értelem szerűen a publikus ip-k és a gateway van.

Miért akarsz natolni a két hálózat között?

A site2-őn mintha mindent az eth0-ra route-olnál, nem jut csomag a tunnelbe bele.

Site2site VPN esetén a fogadó oldallal nem lesz gond, mert minden olyan csomag, ami a VPN-en jön és a cél nem a VPN egy másik végpontja, itt "kiesik" a VPN-ből, így a fogadó oldal - site1 - subnet elérhető lesz a kliens felől - esetünkben site2 -, de a másik irány nem fog működni! Ahhoz, hogy működjön, a fogadó oldalon tudatni kell az OpenVPN-nel, hogy az adott subnet az adott kliensnél érhető el. Ez az iroute opció, amit a site1 konfigjában nem látok. (A probléma az lenne, hogy általában több kliens is van - ilyen esetben melyiknek kell elküldeni a site2 subnetbe tartozó cél IP-jű csomagot? Ok, jelenleg csak egy kliens van - de a döntéshozó mechanizmus nem így lett kihegyezve.)
Az OpenVPN szereti maga osztani a maga logikájával az IP-ket. Ez azért hangsúlyos, mert a régi win/tun driver kitzárólag /30-as subnetet tudott kezelni és kompatibilitási okokból a mai napig ez az alapértelmezés. Ebben az esetben viszont a fogadó a 10.20.2.1 lenne, amihez a 10.20.2.2 fog tartozni mint _virtuális_ IP, a kliens pedig a 10.20.2.6 IP-t kapná, amihez a 10.20.2.5 IP fog tartozni, mint virtuális IP. Az, hogy a kliens konfigban te kikényszeríted a 10.20.2.2 és 10.20.2.1 használatát, nem szép, nem is biztos hogy működik. Ha ebbe az irányba akarsz menni, akkor inkább állítsd át a tun interface használati módját és a "/30 + trükk" helyett legyen egy normális /24 subnet. Itt a topology paraméter subnet beállítására gondolok. :-)
Igazából az a rész sem tiszta, hogy maga a topológia milyen? Ha van két subnet - site1, site2 -, ahol van egy default gw ami a router esélyesen és ezekben a subnetekben van egy-egy dedikált VPN szerver, ami "út a másik site felé", akkor a többi kliens honnan fogja tudni, hogy minden a másik site felé menő csomag nem a default gw felé küldendő, hanem a subnet egy másik gépe felé, az OpenVPN masina felé?
Maga tunel egyébként felépül? A két gép a VPN IP-n látja egymást?