OpenVPN Access Server Portweiterleitung auf Windows Server

Wo steht der Windows Server? Ist der auch im VPN?

Du gehst hier vom VPN in eine VPN Adresse (RFC 1918) über das physikalische Interface ens3 - das kann so nicht klappen, du willst ja kein DNAT über das Internet vom VPN aus wieder in das VPN rein.

Achso. Dann musst du gucken, dass der Dienst auch auf der IP (dem virtuellen Interface) 10.8.0.15 läuft, und ausgangsseitig auch über das Interface spricht.

D.h. du musst ggf. den Dienst erst nach dem VPN starten.

Weiterhin kannst du mit TCPDUMP dir den Verkehr auf dem tun0 Interface angucken und siehst, was rein und raus geht.

Meines Erachtens nach brauchst du für die Rückroute zusätzlich zu dem Masquerading auch ein SNAT auf die öffentliche IP des vServers.

#Allow Traffic from OpenVPN client to eth0
iptables -t nat -A POSTROUTING -o ens3 -s 10.8.0.0/25 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.8.0.0/25 -j SNAT --to-source 185.194.140.***

Das ganze eben noch auf deine IPs anpassen. 185.194.140.*** ist die öffentliche IP meines vServers.

H6G Deine beiden Einträge sind analog; der MASQUERADE wird häufig in Routern heimischer Netzwerke verwendet bei denen die WAN IP nicht fix ist,

hingegen SNAT bei fixer WAN IP

dies als erste Regel bei NAT

-A POSTROUTING -o ens3 -s 10.8.0.0/24 -j SNAT --to-source 185.194.140.###

dann die beiden PREROUTE Regeln bei NAT

1. -A PREROUTING -i ens3 -p tcp -m tcp --dport 29422 -j DNAT --to-destination 10.8.0.15:29422
2. -A PREROUTING -i ens3 -p udp -m udp --dport 29422 -j DNAT --to-destination 10.8.0.15:2942

die folgenden Regeln bei Filter

-A FORWARD -i ens3 -o tun0 -d 10.8.0.15 -p tcp --dport 29422 -j ACCEPT
-A FORWARD -i ens3 -o tun0 -d 10.8.0.15 -p udp --dport 29422 -j ACCEPT

tun0 ist hier das VPN-Device;

H6G wieso machst Du aus /24 ein /25?

mla ich denke die Zeilen 9 und 10 sind grundsätzlich verwirrend, im Kommentar eth0 aber in der Regel ens3 ...

Zitat von mainziman

H6G wieso machst Du aus /24 ein /25?

Weil 10.8.0.128/25 nicht ins Internet soll. Die bekommen bei mir eine andere VPN Konfiguration.

Die Tipps von H6G betreffend Rückroute sind korrekt. Aber das wird immer noch nicht reichen. Denn Du müsstest auch auf dem Windows-Server dafür sorgen, dass IP-Pakete diese Verbindungen betreffend über das VPN zurück geroutet werden. Ich weiß jetzt ad-hoc nicht, wie ich das unter Windows geschickt realisieren würde.

Ich würde daher einen anderen Ansatz wählen. Das VPN das Du Dir eingerichtet hast passt schon so - aber das Fowarding würde ich in diesem Fall nicht mittels Destination-NAT / IPTables machen, sondern ich würde ein Tool wie z.B. socat verwenden um einen Listening-Port zu öffnen und an den internen Server weiterzuleiten.

socat -d -ly TCP4-LISTEN:29422,bind=0.0.0.0,fork,su=nobody TCP:10.8.0.15:29422

Hay,

Zitat von gunnarh

Denn Du müsstest auch auf dem Windows-Server dafür sorgen, dass IP-Pakete diese Verbindungen betreffend über das VPN zurück geroutet werden. Ich weiß jetzt ad-hoc nicht, wie ich das unter Windows geschickt realisieren würde.

vielleicht denke ich zu einfach... sobald der Windows-Rechner sich mit dem Access-Server verbunden hat, hat der Windows-Rechner doch das passende Netz und routing, sofern der Access-Server das passende ifroute schickt?

Im anderen Fall gab es bislang nichts, was ich nicht mit einer statischen Route auf dem Windows-Rechner gelöst hätte ... freilich muss man auch noch daran denken, in der Windows-Firewall die passenden Ports zum VPN-Server zu öffnen.

CU, Peter

Eine eingehende TCP-Verbindung, die vom Linux-VPN-Server nach 10.8.0.15:29422 mittels DNAT weitergeroutet wird scheint am Windows-Server dann mit Source-IP-Adresse des zugreifenden Senders auf.

Also SrcIP:SrcPort -> Dest-IP:DestPort mit DNAT weiter nach FinalDest-IP:DestPort

Der Windows-Server wird Antworten nach SrcIP:SrcPort

SrcIP ist variabel, SrcPort ist variabel

Mit einer statischen Rück-Route ist da also nichts zu machen. Man muss diese Verbindung beim Eingang taggen und so zurückrouten - mit IPTables kein Problem, aber wie man das unter Windows ad-hoc tun würde müsste man erst recherchieren.

CmdrXay ne Du denkst nicht zu einfach, aber gunnarh Du denkst zu kompliziert;

genau dieses Routing wird durch den VPN Client¹ am Windows Server erledigt;

¹ beim Aufbau der Verbindung bekommt der Client wie es CmdrXay bereits erwähnte die Routen,

und damit funktioniert auch die Rückroute;

und bei IPtables ist der MASQUERADE-Dingens auch nicht notwendig;

es sind nur 3 Schritte mit IPtables

mit POSTROUTING und SNAT die NAT-Adressumsetzung definieren

mit PREROUTING das eigentliche Port-Forwarding definieren (jeweils bei den NAT-Regeln)

und den FORWARD Regeln dieses Port-Forwarding auch erlauben (bei den Filter-Regeln);

Hay,

sorry, dass ich da reinquatsche - aber ich sehe die Komplexität nicht?

(Station im Netz: VPN-Client) -> (VPN Server) <- (Server im lokalen Netz: VPN-Client) ist doch ein Netz, zB 10.8.0.1/24... fertig.

ifpush, ifroute richtig, bissl Routing, bissl Firewall... warum braucht man da NAT? Ich brauche jedenfalls keines, ich habe IP-Forward aktiviert, erlaube iptables zwischen den Netzen zu routen und setze einfache statische Routen und kann von meinen Tablet aus z.B. via RDP in mein internes Netz auf eine VM zugreifen oder auch vom NAS ein Video abspielen. Was ist da anders? Ich lerne gerne dazu

Ich brauche noch nicht mal ein Portforward, wenn ich auf meinem VPN-Server eingeloggt bin.

CU, Peter

Hay,

ah, ich kapiere jetzt, was Ihr konstruieren wollt. Anfrage des Programmes direkt an den entsprechenden Port des VPN-Servers und der soll weitergeben...

VPN-Client auf den externen Rechner und die Sache ist gelöst.

CU, Peter

Zitat von gunnarh

Eine eingehende TCP-Verbindung, die vom Linux-VPN-Server nach 10.8.0.15:29422 mittels DNAT weitergeroutet wird scheint am Windows-Server dann mit Source-IP-Adresse des zugreifenden Senders auf.

genau das soll so sein; und wird durch die Routen beim Verbindungsaufbau erledigt;

Zitat von CmdrXay

warum braucht man da NAT?

weil der eigentliche Server (Windows Server) in einem privaten LAN (mit RFC1918 IP) steht, und die RFC1918-IPs des VPNs sich nicht gut machen,

wenn sie am VPN-Server (Access-Server) ins Netz gelangen ...

Hay,

Zitat von mainziman

weil der eigentliche Server (Windows Server) in einem privaten LAN (mit RFC1918 IP) steht, und die RFC1918-IPs des VPNs sich nicht gut machen,

wenn sie am VPN-Server (Access-Server) ins Netz gelangen ...

Steht er bei mir ja auch und es gelangt nichts "ins Netz". Das VPN bildet sein eigenes, dafür ist ein VPN-Tunnel da.

CU, Peter

CmdrXay Du hast ein NAT definiert; ohne NAT keine Adressumsetzung ...

Hay,

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

ja - aber nur generell und nichts spezifisches bezüglich OpenVPN. Das ist alles.

CU, Peter

mainziman Die Route die der VPN-Client am Windows-Server automatisch konfiguriert ist lediglich eine für das 10.8.0.0/24 Netz. Durch das DNAT am Linux-VPN-Server ändert sich die Source-IP-Adresse nicht. Aus Sicht des Windows-Servers kommt da eine Verbindung mit einer öffentlichen IPv4 Source-Adresse daher. Wenn er auf diese antworten möchte, dann geht das nicht durch die 10.8.0.0/24er Route zum Linux VPN-Server zurück sondern geht über die öffentliche Internet-Anbindung direkt hinaus ins Web (mit unerwarteter Source-IP-Adresse des Windows-Servers, nämlich seine im Internet vom Carrier Grade Nat verwendete Adresse). So wird das aber nichts, denn selbst wenn diese Pakete das Ziel erreichen sollten werden sie dort mangels Zuordenbarkeit zu einer bestehenden IP-Verbindung verworfen.

Ich sehe daher mehrere Lösungsmöglichkeiten:

a) nicht nur DNAT sondern auch SNAT am VPN-Linux-Server

b) viel einfacher gleich wie von mir bereits erwähnt mit "socat" arbeiten und die Verbindung am Linux-Server terminieren.

Hay,

Zitat von gunnarh

Die Route die der VPN-Client am Windows-Server automatisch konfiguriert ist lediglich eine für das 10.8.0.0/24 Netz.

mehr braucht es doch nicht.

Wenn auf der externen Arbeitsstation ein VPN-Client läuft und sich mit dem Server verbindet, bekommt er eine IP aus demselben Netz.

Jetzt nur noch die passenden Ports (nehmen wir mal an, Port 80) auf dem Windows-Server (nehmen wir mal an 10.8.0.8) für den Zugriff aus diesem Netz freischalten und man kann voll transparent von der Arbeitsstation aus direkt auf 10.8.0.8:80 zugreifen.

In die server.conf für openvpn muss natürlich die option "client-to-client" rein, wenn man keine Netz zu Netz-Verbindung realisiert (*) und sowohl Windows-Server wie auch der externe Desktop nur einfache clients sind.

(*) Die meisten meiner Configs verbinden transparent zwei lokale Netze. Für einen externen Arbeitsplatz und mein Tablet habe ich ausnahmsweise auch mal echte Clients konfiguriert, die hängen sich dann als interne Stationen rein und ich habe an diesen Geräten Zugriff auf das gesamte Netz.

CU, Peter

mla :Wieso leitest du eigentlich UDP weiter?

btw, ein einfacher SSH-Tunnel reicht nicht aus?

vmk SSH-Tunnel?