VPN és egymást átfedő belső hálózatok

Hálózatok egyéb

Egy probléma megoldásában szeretném kérni tanácsotokat illetve javaslataitokat.

Egy külső cég a belső hálózatunk 3db munkaállomását kívánja időnként karbantartási céllal elérni, ehhez VPN-t kell kiépítenem. A bökkenő ott van, hogy a mi belső hálózati tartományunk, a 192.168.10.0/24 egy másik ügyfelüknél már felhasználásra került. Azt javasolták, hogy végezzek címátfordítást, így számukra 192.168.57.0/24-es hálózat lennénk. Az ő belső hálózatuk 10.200.190.0/24.A VPN kapcsolat fel is áll, és így fest: 

192.168.57.0/24===193.xxx.xxx.xxx...213.xxx.xxx.xxx===10.200.190.0/24

A címátfordítást egy SNAT/DNAT párossal szeretném megvalósítani (pillanatnyilag csak egy hosztra): 


iptables -t nat -A PREROUTING -s 10.200.190.0/255.255.255.0 -d 192.168.57.25 -j DNAT --to-destination 192.168.10.25
iptables -t nat -A POSTROUTING -s 192.168.10.25 -d 10.200.190.0/255.255.255.0 -j SNAT --to-source 192.168.57.25

Vannak más szabályok is a PRE- illetve POSTROUTING-ban, de a biztonság kedvéért ezeket tettem a legelejére.

No és itt a baj, hogy ez így nem megy, csak épp nem értem hogy miért. Próbálnak ping-elni minket, amit tcpdump-pal látok is, szépen jön be a 10.200.190.112-ről az echo request a 192.168.57.25-re, de a célállomás, a 192.168.10.25 már nem kapja meg.

NAT nélkül kipróbáltam, hogy egy a VPN tűzfalunk belső interfészére teszek egy 192.168.57.1-es címet (a 10.1, mint jelenlegi gateway mellé), egy hosztot pedig 192.168.57.25-ös címmel látok el (gateway 57.1), úgy megkapják az echo reply-t. Vagyis ha a belső hálózatunk valóban 192.168.57.0/24 lenne, sima ügy lenne az egész. Sajnos az "éles" gép IP címét nem állíthatom át 10.25-ről, annak a belső hálózatban változatlannak kell maradnia. Mit lehet tenni? Egyáltalán, az egész elgondolás (NAT) működhet egyáltalán?

A tűzfalunk Debian 3.1 (kernel: 2.6.8-2-686), Openswan 2.2.0-8 van fent csomagból, mint minden más is. A konfiguráció egyéb részleteit adott esetben meg tudom adni. Előre is köszönök minden ötletet, javaslatot.

( petya | 2006. 11. 23., cs – 10:12 )

A NETMAP target kell neked. Pont erre van kitalalva.

Köszönöm az ötletet.

Ha jól értelmezem, ez az SNAT/DNAT egy olyan változata, mely nem csak 1-1 IP címet, hanem 1-1 teljes hálózatot rendel össze. Nekem jó lenne az SNAT/DNAT is, mert az szűkebb, mint a NETMAP, és nem is kell az egész hálózatot elérhetővé tennem a külső cég számára, csak 3 hosztot.

Ez a megoldás sem működik. Megnéztem 

iptables -t nat -xnvL

paranccsal, de egyetlen csomag sem fut bele a következő szabályba: 

iptables -t nat -A PREROUTING -s 10.200.190.0/255.255.255.0 -d 192.168.57.0/255.255.255.0 -j NETMAP --to 192.168.10.0/24

,
ahogy korábban a DNAT-ba sem jutott el. Az echo request-ek pedig jönnek folyamatosan.

( Ligend | 2006. 11. 23., cs – 12:13 )

Be kell hogy valljam, kissé talán szerencsétlenül választottam meg a téma címét, és ez némi félreértésre adhat okot.

( x-daemon | 2006. 11. 23., cs – 12:29 )

1. a FORWARD-ban engedelyezve van-e
2. ugyanazon a gepen van-e a DNAT mint a 192.168.10.25 alapertelmezett atjaroja?
3. a DNAT-olo gep route tablaja jo-e?

1. Igen, explicit meg van adva, hogy engedélyezett ez a forgalom. A FORWARD policy DROP, de a statiszika alapján nincs eldobott csomag. Próbáltam áttenni az egész FORWARD-ot ACCEPT-re, de a helyzet változatlan volt.

2. Igen. A 192.168.10.1 a tűzfal/VPN, a belső hálózat gépei számára ez a default route.

3. Olvasatom szerint jó, de mindjárt beillesztem. Ha jól gondolom, a 10.200.190.0/24-ről bejövő csomagok a PREROUTING-ban DNAT-tal egyből átfordulnak 192.168.57.25-ös célcímről 192.168.10.25-re. Ezután jön a routing döntés, és már mennie is kellene a csomagnak a belső interfészre (192.168.10.1), viszont ott már nem jelenik meg. Felmerült bennem is, hogy útvonalválasztási hiba, de valószínűtlennek találom. Viszont ami aggaszt, hogy látszólag nem jut érvényre a címátfordítást végző PREROUTING szabály... 


fw:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
193.xxx.xxx.xxx 0.0.0.0         255.255.255.240 U     0      0        0 eth0
10.1.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth2
172.27.0.0      10.1.0.1        255.255.0.0     UG    0      0        0 eth1
0.0.0.0         193.xxx.xxx.xxx 0.0.0.0         UG    0      0        0 eth0

Ehhez fűznék egy kis magyarázatot. Az eth0 a külső interfész, az eth2 a belső. A tűzfal egy keresztkábellel egy másik tűzfalhoz van kapcsolva, melyen keresztül a 172.27.0.0/16 hálózatot érjük el, illetve abból a mi 192.168.10.0/24-es hálózatunkból érnek el kiszolgálókat. Ez a másik tűzfal nem hozzám tartozik.

Ezeket már néztem, és nem hozott eredményt. Még odáig is elmerészkedtem, hogy a FORWARD-ban a 192.168.0.0/16 forrás és célcímek is átmehettek korlátozás nélkül. Továbbra is fenntartom, hogy szerintem a címárfordítás nem megy, tehát az 57.25-ből nem lesz 10.25, és ez okozza a problémát.

Jelenleg úgy működik a dolog, hogy egy második hálózati kártya is üzemel a gépben, mely szépen megkapta a 192.168.57.25-ös címet, a tűzfalon pedig a belső interfész a 10.1 mellé felhúztam az 57.1-es címet is. Így kifogástalanul megy, bár ettől még az alap probléma fennáll.