Harald Oehlmann schrieb:
Am 31.08.2010 11:55, schrieb Fred Ockert:
Harald Oehlmann schrieb:
Am 31.08.2010 11:16, schrieb Fred Ockert:
Harald Oehlmann schrieb:
Mir geht es um das routen der rohen vpn-Pakete, die ja bei mir udp:443 Pakete sind, also das, was du "geschickter Netzaufbau" nennst. nix Routen !!! das Zauberwort heisst hier Portforwarding!
RW -> dsl0:443 UDP -> 10.10.10.10:443 UDP -> 172.30.30.30:443 udp -> 192.168.17.17:443 udp
Ja, genau das versuche ich. Deshalb habe ich ja auch in SuSE-Firewall unter Maskerading eine Portweiterleitung gesetzt. Nur gehen dann die Rückpakete aus dem falschen dsl-Kanal raus.
bitte nix NATten (ohne Not :) ) wo rennt denn der openVPN-Server ? Masquerading haben ich nirgendwo hier (nur einmal NAT nach aussen...)
Ja, Begriffe sind faszinierend.
openVPN läuft auf dem Server. Dieser hat keine öffentliche IP-Adresse. In Richtung Internet hat dieser den Router-PC mit SuSE. Dieser hat 2 öffentliche IP-Adressen, je dsl eine.
Ich nutze Maskerading (was ich eventuell irreführend mit NAT bezeichnet habe) auf dem Router-PC für alle Pakete (nicht nur VPN Rohpakete), um die nichtöffentliche Server-IP-Adresse (192.168.201.147) für das Internet in die Öffentlichen zu übersetzen.
überredet... (Masquerading/NAT), dabei redest du aber von ausgehenden Verbindungen!!! openVPN wartet aber auf eingehende Verbindungen -... das ist ein bisserl was anderes
Ich vermute, daß das SuSE-Firewall Port Forwarding einfach nicht für mehrere Aussenschnittstellen gemacht ist und daß es deshalb nicht geht.
doch... natürlich hat jder "Kanal" von aussen seinen eigenen Port! Wenn von innen 2 vpn-Server lauschen, dann tun sie das (von aussen gesehen) auf 2 unterschielichen Ports ...alternativ: einer udp, der zweite tcp ... wobei TCP teilweise etwas langsamer ist...
Ich habe nur einen vpn-Server mit einem Port (udp:443), der eben über zwei öffentliche IP-Adressen erreichbar sein könnte.
Noch nie probiert... könnte aber gehen (erst einen Probieren, dann den nächsten) viel einfacher ist es aber 2 Serverinstanzen auf 2 verschiedenen tun-Devices mit je einem eigenen Port laufen zu lassen. Jedem seine eigene Server.conf ...seinen eigenen (öffentlichen) Port ..
Mein Gate nach aussen leitet einen Handvoll Ports auf verschiedene Maschinen weiter [VPN,ssh, smtp,http]...natürlich hat z.B. jeder Webserver (nach aussen) einen anderen Port ! ich.net:10000; ich.net:10001; ich.net:10003 usw. das wird jeweils auf intern1:80 ; intern2;80 und intern3:80 geforwardet
NAT findet nur statt um alle 255 IPs nach aussen auf eine abzubilden (na ja..wie jedes Gate zum Internet eben)
Nach aussen also 88.88.88.88 (eth0) innen 10.10.10.0/24 (eth1)...Beispiel-IPs . also wird 88.88.88.88:443 udp nach 10.10.10.99:1234 geforewardet ...weil dor der VPN-Server lauscht
und der antwortet auch genau dahin (established ).. da geht nix zum Standardgateway...
Das ist so klar. Ich habe das eventuell falsch konfiguriert. Bei mir gehen eben die Rückpakete zum Standardgateway heraus. Eventuell liegt das auch am UDP, da ja da kein Zustand ist und der Maskerading Router PC eventuell nichts speichert.
nein auch UDP weiss, woher die Verbindung gekommen ist Ich würde auf inkorrekten Portforward tippen Oder sag mir, warum das sonst bei dir so nicht geht...na ja ... evtl. kommst du per VPN rein, kannst den (File)Server eine Frage zukommen lassen, aber der kennt den "Weg nach Hause" nicht und schickt den Krempel zum Standardgateway (das tut aber nicht der VPN-Server..) Aber ..erst mal solltest du die Kiste mit dem VPN-Server stabil erreichen können ..testen per ssh-login oder so was in der Art.
Danke, Harald
Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 31.08.2010 13:44, schrieb Fred Ockert:
openVPN wartet aber auf eingehende Verbindungen -... das ist ein bisserl was anderes
Richtig, die Initiative kommt von der anderen Seite. In der SuSE-Firewall sind beide verknüpft, da sie gemeinsame Teile haben, das IP-Adressen-Umschreiben.
Noch nie probiert... könnte aber gehen (erst einen Probieren, dann den nächsten) viel einfacher ist es aber 2 Serverinstanzen auf 2 verschiedenen tun-Devices mit je einem eigenen Port laufen zu lassen. Jedem seine eigene Server.conf ...seinen eigenen (öffentlichen) Port ..
Meine ich auch.
Das ist so klar. Ich habe das eventuell falsch konfiguriert. Bei mir gehen eben die Rückpakete zum Standardgateway heraus. Eventuell liegt das auch am UDP, da ja da kein Zustand ist und der Maskerading Router PC eventuell nichts speichert.
nein auch UDP weiss, woher die Verbindung gekommen ist Ich würde auf inkorrekten Portforward tippen Oder sag mir, warum das sonst bei dir so nicht geht...na ja ... evtl. kommst du per VPN rein, kannst den (File)Server eine Frage zukommen lassen, aber der kennt den "Weg nach Hause" nicht und schickt den Krempel zum Standardgateway (das tut aber nicht der VPN-Server..) Aber ..erst mal solltest du die Kiste mit dem VPN-Server stabil erreichen können ..testen per ssh-login oder so was in der Art.
Vermute ich auch. Für Port forwarding braucht es auch keinen Zustand, da ja IP:Port eindeutig sind. Rein: Zieladresse=IP,Port, Raus: Quelladresse=IP,Port, fertig, ganz einfach, funktioniert alles, fliegt nur aus dem falschen Interface raus... Port forwarding und Routing sind einfach getrennte Kisten. Das Port forwarding schaut: Ziel=IP:Port -> Ziel-IP ersetzen und routen. Und zurück: Quelle=IP:Port -> Quell-IP ersetzen und routen. Nur routet es dann aus dem falschen Interface... Danke, Harald -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Harald Oehlmann
Am 31.08.2010 13:44, schrieb Fred Ockert:
openVPN wartet aber auf eingehende Verbindungen -... das ist ein bisserl was anderes
Richtig, die Initiative kommt von der anderen Seite. In der SuSE-Firewall sind beide verknüpft, da sie gemeinsame Teile haben, das IP-Adressen-Umschreiben.
Noch nie probiert... könnte aber gehen (erst einen Probieren, dann den nächsten) viel einfacher ist es aber 2 Serverinstanzen auf 2 verschiedenen tun-Devices mit je einem eigenen Port laufen zu lassen. Jedem seine eigene Server.conf ...seinen eigenen (öffentlichen) Port ..
Meine ich auch.
Das ist so klar. Ich habe das eventuell falsch konfiguriert. Bei mir gehen eben die Rückpakete zum Standardgateway heraus. Eventuell liegt das auch am UDP, da ja da kein Zustand ist und der Maskerading Router PC eventuell nichts speichert.
nein auch UDP weiss, woher die Verbindung gekommen ist Ich würde auf inkorrekten Portforward tippen Oder sag mir, warum das sonst bei dir so nicht geht...na ja ... evtl. kommst du per VPN rein, kannst den (File)Server eine Frage zukommen lassen, aber der kennt den "Weg nach Hause" nicht und schickt den Krempel zum Standardgateway (das tut aber nicht der VPN-Server..) Aber ..erst mal solltest du die Kiste mit dem VPN-Server stabil erreichen können ..testen per ssh-login oder so was in der Art.
Vermute ich auch. Für Port forwarding braucht es auch keinen Zustand, da ja IP:Port eindeutig sind. Rein: Zieladresse=IP,Port, Raus: Quelladresse=IP,Port, fertig, ganz einfach, funktioniert alles, fliegt nur aus dem falschen Interface raus...
Port forwarding und Routing sind einfach getrennte Kisten. Das Port forwarding schaut: Ziel=IP:Port -> Ziel-IP ersetzen und routen. Und zurück: Quelle=IP:Port -> Quell-IP ersetzen und routen. Nur routet es dann aus dem falschen Interface...
da hilft dann route(8) add -net <adresse> gw <adresse> device -Dieter -- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 31.08.2010 14:23, schrieb Dieter Kluenter:
Harald Oehlmann
writes: Port forwarding und Routing sind einfach getrennte Kisten. Das Port forwarding schaut: Ziel=IP:Port -> Ziel-IP ersetzen und routen. Und zurück: Quelle=IP:Port -> Quell-IP ersetzen und routen. Nur routet es dann aus dem falschen Interface...
da hilft dann route(8) add -net <adresse> gw <adresse> device
Hallo Dieter, danke, ich habe eben ein (tolles Wort) "Policy Routing" aufgesetzt, siehe heutigen Anfang vom Thread, damit nur "Protokoll=udp, Port=443,Ziel=Internet" auf ein anderes (nicht default route) Interface geroutet werden. Es ist leider so, daß "route add -net" eben nicht geht, da beide Interface (dsl0 und dsl1) ins Internet und damit in das selbe Netz zeigen. Es kann sogar sein, daß von der selben Maschine aus dem Internet Pakete kommen, die einmal via dsl0 und einmal via dsl1 rein- und raus gehen. Danke, Harald -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Harald Oehlmann schrieb:
Es ist leider so, daß "route add -net" eben nicht geht, da beide Interface (dsl0 und dsl1) ins Internet und damit in das selbe Netz zeigen. Es kann sogar sein, daß von der selben Maschine aus dem Internet Pakete kommen, die einmal via dsl0 und einmal via dsl1 rein- und raus gehen.
nööö da bist du falsch... du sollst beim Manual lesen nicht nach dem dritten Satz aufhören :) Du gibst ein Gate an mit einer konkreteten IP und einem konkreten Zielnetz, das hat (normalerweise) nicht 2 Möglichkeiten (gibts erst mit Multipath Router Software...aber nicht alles auf einmal..) ansonsten gibt es auch eine dev Option! Brauch ich auch, um festzulegen was über welchen Tunnel geht (File)Server 192.168.0.222 : route add -net 10.10.10.0/24 gw 192.168.0.1 route add -net 10.10.11.0/24 gw 192.168.0.1 (VPN-Server)192.168.0.1: route add -net 10.10.10.0/24 dev tun0 route add -net 10.10.11.0/24 dev tun1 usw. ... komsst du eins-fix-drei drauf, wenn du dir den konkrten Paketweg z.B. aufmalst :)
Danke, Harald
Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Harald Oehlmann
Am 31.08.2010 14:23, schrieb Dieter Kluenter:
Harald Oehlmann
writes: Port forwarding und Routing sind einfach getrennte Kisten. Das Port forwarding schaut: Ziel=IP:Port -> Ziel-IP ersetzen und routen. Und zurück: Quelle=IP:Port -> Quell-IP ersetzen und routen. Nur routet es dann aus dem falschen Interface...
da hilft dann route(8) add -net <adresse> gw <adresse> device
Hallo Dieter,
danke, ich habe eben ein (tolles Wort) "Policy Routing" aufgesetzt, siehe heutigen Anfang vom Thread, damit nur "Protokoll=udp, Port=443,Ziel=Internet" auf ein anderes (nicht default route) Interface geroutet werden.
Es ist leider so, daß "route add -net" eben nicht geht, da beide Interface (dsl0 und dsl1) ins Internet und damit in das selbe Netz zeigen. Es kann sogar sein, daß von der selben Maschine aus dem Internet Pakete kommen, die einmal via dsl0 und einmal via dsl1 rein- und raus gehen.
Hier geht es doch nicht um den Zugang zum Internet, hier geht es darum, eine Tunnel durch das Internet zum vpn-Partner zu bauen. Der Tunnel hat häufig ein virtuelles tune Device und einen eigenen Adressraum, der vpn-Partner hat auch einen eigenen Adressraum. Die Route zum Adressraum des vpn-Partners geht über das Gateway des Tunnel Adressraums und kann zusätzlich mit einer Devicebezeichnung spezifiziert werden. Zum Beispiel: das eigene lokale Netz hat den Adressraum 192.168.100.0/24 der Adressraum des vpn-Partners ist 192.168.200.0/24 das tune Device die Adresse 10.10.10.10 tune Device der Befehl sieht dann wie folgt aus: route add -net 192.168.200.0/24 gw 10.10.10.10 dev tune -Dieter -- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Harald Oehlmann schrieb:
Vermute ich auch. Für Port forwarding braucht es auch keinen Zustand, da ja IP:Port eindeutig sind. Rein: Zieladresse=IP,Port, Raus: Quelladresse=IP,Port, fertig, ganz einfach, funktioniert alles, fliegt nur aus dem falschen Interface raus...
Port forwarding und Routing sind einfach getrennte Kisten. Das Port forwarding schaut: Ziel=IP:Port -> Ziel-IP ersetzen und routen. Und zurück: Quelle=IP:Port -> Quell-IP ersetzen und routen. Nur routet es dann aus dem falschen Interface...
deswegen versteh ich dein Problem nicht ! zum VPN-Server muss amn nicht (zwingend) routen! der ist intern... Der Roadwarrior kommt allerdings (!) mit seiner VPN-Addresse..die musst du (intern auch) routen. Hier haben die Server Routeneinträge für die VPN-Netze und die lokalen Netze (weit weg) hinter den Tunneln sowie für Rechner in der DMZ... VPN selbst ist per Portforward direkt erreichbar. Also..nehmen wir an (der Feind schläft...) öffentlich 8.8.8.8 VPN Tunnel(Server) 10.10.10.1 File Server 192.168.168.168 RW eth0:192.168.0.100 M;; tun0 10.10.10.6 der RW connectet den Fileserver: dann braucht der File Server einen Routingeintrag (Standardgate, welches die Route kennt) für das VPN-Netz (10.10.10.), der RW muss (per openVPN.conf) das Netz 192.168.168. kennen; Viel mehr sollte nicht sein...als Basis
Danke, Harald
Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (3)
-
Dieter Kluenter
-
Fred Ockert
-
Harald Oehlmann