VPN Tunnel IP für internes Netzwerk maskieren/natten?

[Kidaru]

Hallo Gemeinde,

Ich zergrüble mir schon seit Tagen den Kopf wie ich der DS beibringe die IP des VPN Tunnels auf das interne eth zu natten bzw. zu maskieren.
Dazu folgende Situation, mein Heimrechner (192.168.0.2) baut über meinen Gateway Rechner (192.168.0.1) einen OpenVPN Tunnel zur DS (2XX.XXX.XXX.30 feste öffentliche IP) auf. Soweit so gut. von meinem Heimrechner erreiche ich auch beide Netzwerkschnittstellen der DS, eth0 und eth1. Allerdings komme ich nicht in das interne Netzwerk welches über eth1 (10.1XX.XXX.8) erreichbar sein sollte. IP forwarding ist auf der DS eingeschalten. Ich habe daher die Vermutung das ich noch der Tunnel IP (im Bereich 10.10.10.0/24) bei bringen muss Anfragen in das interne Netz von eth1 zu natten bzw. zu maskieren.
Ein Vorschlag mit "route add" oder "iptables" wäre ganz hilfreich, ich muss nur beachten das die DS im produktiven Einsatz ist und ich nicht viel Spielraum für Experimente habe.

Was jedoch problemlos funktioniert ist die Erreichbarkeit des internen Netzes wenn ich direkt per ssh auf der DS eingeloggt bin, die derzeit gesetzten Routen selbst stimmen also.

Ich kann mir vorstellen das die Lösung echt simpel ist, aber irgendwie habe ich gerade einen Knoten im Denkprozess.

Danke und Grüße
Kidaru

 

[jahlives]

du musst für die entfernten Servernetze auf dem Server der OpenVPN als Daemon auf Port 1194 laufen lässt entsprechende Routen erstellen. Sagen wir das remote Netz ist 192.168.0.0/24 und der client ist mit 10.100.0.8 am OpvenVPN verbunden

route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.100.0.8 dev tun0

zusätzlich muss du in der OpenVPN Konfiig auf dem Server das entfernte Netz via route-Parameter eintragen

route 192.168.0.0 255.255.255.0

in der openvpn Server Konfig
Btw verwendest du den OpenVPN von Synology oder hast du openvpn via ipkg installiert?

 

[Kidaru]

ipkg hab ich gar nicht drin, ich nutze das OpenVPN von Synology und die zusätzlichen Routeneinstellungen im/fürs Netzwerk werden über rc.local geladen. So hab ich wenigstens nur eine Fehlerquelle an der ich schuld sein kann. ^^

Nur nochmal zum Verständnis ob ich begriffen habe, (und auf mein Netz bezogen)
Bsp:

route add -net 10.177.135.0/24 gw 10.10.10.6 dev tun0

heißt: füge eine route hinzu, ins netz 10.177.135.0 mit der netzmaske 255.255.255.0, für alles was von 10.10.10.6 kommt und schicke diese daten an das interface tun0 ?

und

Bsp:

route 10.177.135.0 255.255.255.0

nutze für die route ins netz 10.177.135.0/24 nicht das standard gateway ?

 

[CaptainKrunch]

Nur nochmal zum Verständnis ob ich begriffen habe, (und auf mein Netz bezogen)
Bsp:

route add -net 10.177.135.0/24 gw 10.10.10.6 dev tun0

heißt: füge eine route hinzu, ins netz 10.177.135.0 mit der netzmaske 255.255.255.0, für alles was von 10.10.10.6 kommt und schicke diese daten an das interface tun0 ?

Nein. Es wird gedeutet als: alles, was ins Netz 10.177.135.0/24 gehen soll, schicke bitte über das Gateway mit der IP-Adresse 10.10.10.6, das seinerseits über das Device tun0 erreichbar ist.

 

[jahlives]

route auf dem Server sollte so aufgebaut sein

route add -net ENTFERNTES_NETZ netmask 255.255.255.0 gw OPENVPN_IP_CLIENT dev DEIN_TUN_INTERFACE

d.h. alles was für ENTFERNTES_NETZ bei deinem Server ankommt wird an die OpenVPN IP des entsprechenden Clients gegeben und das via tun Interface (dev)

[LEFT][COLOR=#333333]route 10.177.135.0 255.255.255.0

das ist eine andere Art der Route und sagt dem OpenVPN Server, dass er dieses Netzwerk ebenfalls via OpenVPN erreichen kann. Beide sind nötig. Zusätzlich solltest du dir das ipkg openvpn angucken. Denn damit sind auch routingtechnisch Dinge möglich, die du mit dem OpenVPN von Syno ned machen kannst. Wichtig ist, dass du dazu das tun Interface im sogenannten subnet Modus laufen lässt, erst damit kann man easy routen (im Wiki haben wir mehr dazu)
[/COLOR][/LEFT]

 

[goetz]

Hallo,
eigentlich sollte die DS bereits selbst eine NAT Regel angelegt haben, schau mal ob sie da ist

iptables -t nat -L

Gruß Götz

 

[Kidaru]

route add -net ENTFERNTES_NETZ netmask 255.255.255.0 gw OPENVPN_IP_CLIENT dev DEIN_TUN_INTERFACE

dann wäre das die Angabe der Rückroute zu meinem Heimrechner ? hier wird aber noch nichts maskiert oder genattet. auch wegen der angabe des der client ip, es sind ja mehrere clients möglich.


@Götz, das zeigt er an

ODIN> iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.10.10.0/24        anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ODIN>

 

[jahlives]

@goetz
NAT ist eigentlich unnötig, wenn man den opevpn von ipkg installiert. OpenVPN unterstützt seit Version 2.1 am tun interface auch die Topology subnet. Syno verwendet hingegen subnet30 was effektiv eine p-t-p-Verbindung ist (dort braucht man NAT). Im Subnet Modus kannst du jedoch ohne NAT arbeiten und alles via Routing erledigen (setzt einfach voraus, dass ipforward aktiviert ist und mindestens OVPN 2.1 installiert ist, auch die Clients)
Ne bequemere Art als via subnet kenn ich ned, erfordert auf jeden Fall am wenigsten Konfig

Oder wird via ipkg eine Version < 2.1 installiert? Kann das leider mangels DS mit Firmware ned nachprüfen. Müsste sich aber auf der Konsole rausfinden lassen

 

[goetz]

Hallo,
die NAT Regel ist vorhanden,

Chain POSTROUTING (policy ACCEPT) 
target     prot opt source               destination          
MASQUERADE  all  --  10.10.10.0/24        anywhere

alles was von 10.10.10.0/24 kommt und irgendwo hin will wird maskiert (genattet). Jetzt ist die Frage wie sieht die Routingtabelle auf der DS aus?

Gruß Götz

 

[jahlives]

Ich würde nach Möglichkeit ned natten ;-) Machts nur komplizierter und auch anfälliger: Die src ist immer gleich dem ovpn Interface des Servers, damit wird es mit granulierten Firewallregeln schwierig. Blockt eine Firewall auf dem Client, dann ist gleich die gesamte openvpn Verbindung des Clients platt. Beim Routing hingegen kommt die effektive IP des verbindenden Clients an und eine Firewall kann viel gezielter sperren.

Bei routing geht dann folgendes

C:\Windows\system32>tracert 192.168.11.1


Routenverfolgung zu 192.168.11.1 über maximal 30 Abschnitte


  1    <1 ms    <1 ms    <1 ms  192.168.199.1
  2    <1 ms    <1 ms    <1 ms  narvik [192.168.199.7]
  3    40 ms    54 ms    38 ms  soki.local [10.66.77.3]
  4    40 ms    39 ms    42 ms  192.168.11.1

dabei ist mein Client selber die 192.168.199.11 und 192.168.11.1 ist der Router des entfernten Netzes (steht bei uns im Büro). aus dem Büro verbindet sich eine Client 192.168.11.33 ans OpenVPN und bekommt die interne IP 10.66.77.3. Die Pakete gehen also ohne NAT vom Client an meinen Router, von dort an den Server, welcher das OpenVPN aufbaut, dort durch eine Route an 10.66.77.3 und damit das entfernte Netz. Der Client im entfernten Netz schickt die Pakete dann an seinen eigenen Router. Der Vorteil: Jede Station hat als src meine LAN-IP 192.168.199.11

 

[jahlives]

Habe gerade meine alte 408 entstaubt und die Firmware und ipkg installiert. OpenVPN ist in Version 2.2 vorhanden und sollte damit subnet unterstützen. Da würde ich auf jeden Fall den ipkg OpenVPN verwenden

testserver> ipkg list | grep openvpn
openvpn - 2.[B]2[/B].0-1 - SSL based VPN server with Windows client support

 

[Kidaru]

au weia, bitte nicht gegenseitig schlagen ...

Ihr habt beide interessante Ansätze, derzeit wäre aber das "natten" aus dienstlichen Gründen sinnvoller.
ipkg ist zwar recht interessant aber ich möchte es nicht installieren, die DS soll soweit wie nur irgend möglich "original" bleiben.
Es muss nicht immer die neueste Software sein, es muss nur dauerhaft stabil funktionieren.
Wohl auch ein Grund warum mein Gateway Rechner zu Hause schon über 16 Jahre alt ist, ich die LTS Versionen von Ubuntu bevorzuge
und alte Hardware bewundere die selbst Tonnen von Staub und Hitze ohne Kühlkörper gewachsen ist. ... ich merke gerade ich schweife ab ...


@Götz / @jahlives

die derzeitige Routing Tabelle direkt auf der DS

ODIN> route       
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.2      *               255.255.255.255 UH    0      0        0 tun0
2XX.XXX.XXX.X24 *               255.255.255.248 U     0      0        0 eth0
10.177.135.0    *               255.255.255.0   U     0      0        0 eth1
10.159.174.0    10.177.135.253  255.255.255.0   UG    0      0        0 eth1
10.10.10.0      10.10.10.2      255.255.255.0   UG    0      0        0 tun0
210.224.208.0   10.177.135.9    255.255.255.0   UG    0      0        0 eth1
default         2XX.XXX.XXX.X25 0.0.0.0         UG    0      0        0 eth0
ODIN>

die IP Adressen mit "X" musste ich leider verschleiern, da fest und öffentlich
der IP Bereich mit "210. ..." ist eine Adressvergabe aus Zeiten der Dinosaurier, aber ein interner Adressbereich der keine Verbindung ins öffentliche Netz hat und den ich nicht ändern kann.


und schon mal Danke euch Beiden für die Hilfe

 

[jahlives]

Wir schlagen uns schon nicht, keine Angst (v.a. weil mich der Berliner Bär noch vor dem Frühstück verspeisen würde) ;-)
Ist denn deine DS selber der OpenVPN Server d.h. verbinden sich deine Clients via OpenVPN an die DS? Dann braucht die DS keine Gateway Route für ihr eigenes OpenVPN Netz. Bei mir auf dem OpenVPN Server schauen die Routen so aus

root@jokkmokk: ~ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.199.201 0.0.0.0         255.255.255.255 UH    0      0        0 venet0
192.168.199.200 0.0.0.0         255.255.255.255 UH    0      0        0 venet0
192.168.199.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1-eth0
192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.66.77.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.11.0    10.66.77.3      255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.200.1   0.0.0.0         UG    0      0        0 eth0

dabei ist das 10.66.77./24 das Sub des OpenVPN selber und für das entfernte LAN (hinter einem OpenVPN Client) gibt es eine Route an den entsprechenden OpenVPN Client (10.66.77.3). die anderen Einträge meiner Routen brauchst du ned ;-)
Ich bin mir aber ehrlich gesagt nicht ganz sicher ob dein Vorhaben mit einem subnet30-OpenVPN überhaupt funzen kann. Denn der Server hat für jeden OpenVPN-Client eine andere IP, weil opevpn ja eine ptp-Verbindung aufbaut. Das zu natten wird schwieriger (zumindest wüsste ich ned wie ich das sauber hinkriegen könnte)

 

[goetz]

Hallo,
au ja Schlägerei!!
@jahlives
ich hoffe wir sehen uns auf der CEBIT

jahlives beschreibt den Weg "wie man es richtig macht", ich schaue ob man auch mit kleinen Brötchen zum Ziel kommt, scheint ja ein Sonderdrösel nur für Dich zu sein.
iptables ist inzwischen ja viel gesprächiger geworden, deshalb meine Bitte

iptables -t nat -nvL

Gruß Götz

 

[jahlives]

iptables -t nat -nvL

ich könnte dir meine iptables zeigen. die ist schon mit subnet OpenVPN sehr gross. Möchte ned wissen wie gross die wäre wenn ich es natten würde bzw würden viele der Regeln gar nicht mehr funzen
Wegen der CeBit bin ich bis heute noch nicht sicher. Ich denke, das werde ich eher kurzfristig entscheiden

 

[Kidaru]

Wir schlagen uns schon nicht, keine Angst (v.a. weil mich der Berliner Bär noch vor dem Frühstück verspeisen würde) ;-)
Ist denn deine DS selber der OpenVPN Server d.h. verbinden sich deine Clients via OpenVPN an die DS? Dann braucht die DS keine Gateway Route für ihr eigenes OpenVPN Netz. Bei mir auf dem OpenVPN Server schauen die Routen so aus

Ja, die DS ist selbst der OpenVPN Server und steht mit einem "Bein" (eth0) im Internet und mit dem anderen (eth1) im internen Netzwerk. Und was die OpenVPN Version der DS angeht, ich meine es ist 2.0 zumindest steht das in der server.conf, zu finden in /volume1/@appstore/VPNCenter/etc/openvpn

bzw.

cat /volume1/@appstore/VPNCenter/etc/openvpn/server.conf

... und für goetz

ODIN> iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 16487 packets, 2482K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 1601 packets, 237K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   97 14221 MASQUERADE  all  --  *      eth0    10.10.10.0/24        0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 1594 packets, 236K bytes)
 pkts bytes target     prot opt in     out     source               destination         
ODIN>

 

[jahlives]

wieso schickst du das 10-er Netz (ich nehm an das ist dein OpenVPN) an eth0? Da würde auch OpenVPN-interne Pakete an eth0 schicken. Die müssen aber in jedem Fall ans tun Interface. Da müsstest du dann aber eine route an eth0 fürs OpenVPN Sub zurück ans tun-Interface machen. Das ist der Hacken beim natting, du kannst fast nicht mehr unterscheiden was intern und was extern ist. Diese Regel oben bei dir ist dafür da dass OpenVPn Clients ihren Traffic via DS ins Netz (nach extern) schicken können. Dazu ersetzt die DS die Absender IP mit ihrer eigenen und schickt das Paket an den default Gateway. imho führt diese Regel dazu, dass zuviel Traffic weitergeleitet wird, nämlich auch Pakete die intern wären und eigentlich nur zwischen eth und tun hin-und her müssten

 

[Kidaru]

@jahlives

händisch hab ich da nichts geändert, wenn dann sind das die Einstellungen die vom OpenVPN Server beim einrichten gemacht wurden. Die Standard VPN Adressen sind 10.8.0.0/24 die habe beim einrichten über den DSM selbst auf 10.10.10.0/24 festgelegt (sieht nur schicker aus)


@goetz

könnte man einen PREROUTING Eintrag in die Chain machen mit target MASQUERADE, out eth1, source 10.10.10.0/24 und destination 10.177.135.0/24 ?

 

[jahlives]

ganz ehrlich: ich glaub ned, dass du mit nat auf einen grünen Zweig kommen wirst. Schau doch mal mit tracert (windows) bzw traceroute (linux) wie genau deine Pakete verlaufen. Damit kann man u.U. erkennen wo die Pakete hängenbleiben. Auch Whireshark kann in solchen Fällen helfen oder auch tcpdump (allerdings weiss ich ned ob tcpdump auf der DS mitdabei ist)

 

[goetz]

Hallo,
irgs, das kann ja nicht funktionieren, Du willst ja nach eth1 raus.
Temporärer Versuch

iptables -t nat -I POSTROUTING 1 -s 10.10.10.0/24 -o eth1 -j MASQUERADE

@jahlives
der soll gefälligst die Pakete aus dem VPN-Netz an eth1 schicken, da sind die 10.177.135.X zu finden.

@Kidaru
evtl. mal das VPN-Netz im DSM auf 172.16.1.0/24 umstellen.

Gruß Götz