openvpn gateway portweiterleitung/öffnung

[hooligan]

hejhej

ich habe auf einem debian vserver einen vpngateway installiert.
läuft auch soweit.

meine frage ist jetzt wie bekomme ich ein paar ports für zb eMule, torrent etc geöffnet.

ich denke theoretisch müsste folgendes helfen:
[src=text]
iptables -t nat -A PREROUTING -p tcp -i venet0:0 --dport 28020:28025 -j DNAT --to 10.8.0.6
iptables -t nat -A PREROUTING -p udp -i venet0:0 --dport 28020:28025 -j DNAT --to 10.8.0.6
[/src]

meinem verständnis nach wird damit tcp/udp port 28020 bis 28025 für den client mit der local ip 10.8.0.6
über den netzwerkadapter venet0:0 der bei mir nach aussen geht.

wer kann und mag helfen?

 

[Metal_Warrior]

@hooligan:
Ich mag mich ja irren (soll öfter mal vorkommen), aber wozu solltest du bei deinem Debian VPN-Server Ports öffnen müssen (abgesehen von dem, über den deine VPN-Verbindung läuft)?

VPN ist eine Tunneltechnik, d. h. du verbindest dich zu einem Port auf einem Server und baust dorthin eine stetige Verbindung auf, über die alle anderen Programme ihren Traffic routen. Das läuft normalerweise so ähnlich wie FTP over SSH - SSH stellt den Tunnel bereit, FTP nutzt ihn. Dazu wird auch kein weiterer Port angewählt, alles läuft hübsch verschlüsselt über die 22. Also ich sehe höchstens ein Problem in der Konfiguration deiner Firewall oder deines VPN-Servers, der bestimmte Protokolle nicht zulässt. Mehr kann ich leider nicht erkennen.

Oder möchte mich da jemand korrigieren?

 

[hooligan]

wenn man zb bei nvpn ist muss man sich auch ports für zb eMule, torrent etc freischalten lassen.
sonst geht nur webtraffic durch.

zumal sonst emule keine high id bekommt(wem es noch was sagt ;-) )

ich hatte es früher auf einem anderen server schonmal zum laufen gebracht.
nur leider war das darmals try and error, da ich absolut keinen plan hatte :-D

 

[Metal_Warrior]

wenn man zb bei nvpn ist muss man sich auch ports für zb eMule, torrent etc freischalten lassen.

Natürlich sollte ein VPN-Server durchaus in der Lage sein, einzelne Protokolle zu unterbinden bzw. anders zu behandeln als andere. Das hat nur nichts mit den Netzwerkadaptern zu tun, oder mit iptables. Deine Serveranwendung muss das können und durchlassen, nicht irgendwas anderes. Was sagen denn deine Logs, wenn du mal ein paar Verbindungen ausprobierst?

 

[hooligan]

der server soll wissen wenn was auf port 21081 kommt das er zu client1 weiterschicken soll etc
und das hängt mit iptables zusammen. hab es schließlich dadrüber schonmal gemacht.

 

[Metal_Warrior]

der server soll wissen wenn was auf port 21081 kommt das er zu client1 weiterschicken soll etc

Ja und nein. Der Erstaufbau der Tunnelverbindung DARF gar nicht weitergesendet werden, sondern muss auf der Serveranwendung enden. Den Rest sollte meinem Verständnis nach die jeweilige Anwendung serverseitig selber machen, d. h. die Pakete, die aus dem Tunnel kommen, unwrappen, decrypten und dann als reguläre Pakete an den eigentlichen Zielserver weiterverschicken. Würden die einfach nur weitergeleitet werden, bekämen die Zielserver nur Datenmüll, weil verschlüsselt mit einem Key, den nur dein Client und der VPN-Server hat. Letztendlich ist das VPN auf Serverseite also kein reines Durchrouten, sondern eine eingehende verschlüsselte Kommunikation, welche am Ende den Server verlassen muss als direkte Anfrage. Der Empfänger darf ja nicht ahnen, dass die Pakete nicht am Server ihren Zielort erreicht haben, sondern nur eine Zwischenstation. Kurzum:

Client ---encrypted---> VPN-Server>NAT-Gateway ---cleartext---> Target

Und so wie ich Linux kenne, regelt der jeweilige Paketmanager bei der Installation die weiteren Befindlichkeiten, so dass die Serveranwendung selbst nur noch in ihrer Config-Datei verändert werden muss.

Ich frag aber gern nächste Woche mal unsere Jungs, wie die das mit dem ASA-Cluster so handhaben... Immerhin brauch ich das wohl auch bald.