Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?
-
Puh, Strato hatte ich schon lange nicht mehr, weil mich Preis/Leistung für Privatzwecke nicht überzeugt hat.
Mir fallen da spontan 2 Möglichkeiten:
- der vServer nutzt ein Linux-System, das gar kein iptables mehr zur Verfügung stellt sondern auf Alternativen setzt.
- in der Konfiguration der Repositorys stehen derzeit (abgespeckte) Strato-Repos, die sich durch die offiziellen Repos austauschen lassen um so iptables nach zu installieren.
-
Das ist immer das erste was ich mit so einem Server mache :-)
In dem Fall ist das anders, weil ich keine eigene Module laden kann usw. Daher wahrscheinlich eine OpenVZ/Container Lösung.
Welchen Anbieter würdest du denn empfehlen? Vor über 10 Jahren war ich mal Kunde bei Netcup. Domain + Vserver.
Sehe gerade, kosten die hälfte und dort steht sogar explizit das per KVM virtualisiert wird.
https://www.netcup.eu/vserver/vps.php#v-server-details
Habe gerade einen von Strato, für 5€ im Monat. Habe auch nur dort einen gemietet, weil ich dort bereits einige Domains habe.
-
Netcup wäre für private Zwecke auch meine Empfehlung gewesen. Die KVM-Virtualisierung macht richtig Spaß und die Ausfallzeiten sind sehr gering. Insbesondere für den Preis.
-
1 Kern reicht denke ich mal für ein bzw zwei Clienten? Also wegen OpenVPN und der stattfindenen Verschlüsselung während der Datenverkehr fließt.
-
Ich würde das mit der neuen vCloud von Hetzner mal probieren. Meine paar Instanzen dort sind zum einen super günstig und nach einem doofen Start mit einer davon auch voll Dual Stack ausstaffiert.
Könnte da notfalls mal testhalber OVPN draufladen, aber soweit ich das sehe (ich habe da Ubuntu 18.04 LTS Instanzen laufen), sehen die ein sauberes eth0 mit IP4/IP6. Mein Fail2Ban mit IPtables/NFtables und Fail2ban läuft da auch fein drauf. Vermutlich Kubernete oder KVM sauber virtualisiert - hatte noch keine Schwierigkeiten damit. Diese Pseudo-Containerisierung von manchen "vServern" ist echt gruselig... und die knapp 3€/mtl. sind kein Problem für nen Test (weniger wenn man mit der Kiste nur nen Tag spielt).
-
@JeGr said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:
Könnte da notfalls mal testhalber OVPN draufladen, aber soweit ich das sehe (ich habe da Ubuntu 18.04 LTS Instanzen laufen), sehen die ein sauberes eth0 mit IP4/IP6. Mein Fail2Ban mit IPtables/NFtables und Fail2ban läuft da auch fein drauf. Vermutlich Kubernete oder KVM sauber virtualisiert - hatte noch keine Schwierigkeiten damit. Diese Pseudo-Containerisierung von manchen "vServern" ist echt gruselig... und die knapp 3€/mtl. sind kein Problem für nen Test (weniger wenn man mit der Kiste nur nen Tag spielt).
Danke für den Tipp!
Bin nun bei Netcup. Und soweit läuft nun alles so wie ich es will. OpenVPN installiert und eingerichtet usw. Kann mich mit nem Smartphone oder Notebook zb aus dem Mobilnetz mit dem Server verbinden.
Gerade kämpfe ich mich bei der Konfiguration von pfSense durch. Das will noch nicht wie ich will.
Bin mal so faul, und kopiere ein Teil der Konversation die ich mit Libratix geführt habe bzw dem geschrieben habe:
Alles ist erledigt. Also Domain ist umgezogen und funktioniert. Server mit OpenVPN mit client-to-client eingerichtet, und Verbindung zum OpenVPN Server funktioniert auch. Jetzt muss ich nur noch den PFsense Router zuhause so konfigurieren, das er sich mit dem OpenVPN Server verbindet, aber jeglichen Traffic weiterhin "durch meine Internetleitung feuert" und nicht durch den VPN. Außer natürlich das, was durch den VPN angefragt wird. Kannst du mich darin unterstützen? Gehe übrigens hier nach: https://gist.github.com/InQuize/59e7c458c510ae779743 Und für die Konfiguration habe ich die exportierte ovpn Datei als Vorlage genommen: client dev tun proto udp remote 1.1.1.1 1111 resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server auth SHA512 cipher AES-256-CBC ignore-unknown-option block-outside-dns block-outside-dns verb 3 <ca> -----BEGIN CERTIFICATE----- ganz geheim 1 -----END CERTIFICATE----- </ca> <cert> -----BEGIN CERTIFICATE----- ganz geheim 2 -----END CERTIFICATE----- </cert> <key> -----BEGIN PRIVATE KEY----- ganz geheim 3 -----END PRIVATE KEY----- </key> <tls-crypt> -----BEGIN OpenVPN Static key V1----- ganz geheim 4 -----END OpenVPN Static key V1----- </tls-crypt> Leider verbindet sich die pfsense nicht. Verbose habe ich auf 4 stehen, und sehe kein Grund weswegen: https://pastebin.com/mkFRzYCFEdit: Sehe gerade das der pastebin aus irgendeinem Grund entfernt worden ist. Poste ich einfach mal direkt hier:
Restart pause, 10 second(s) NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Re-using SSL/TLS context Control Channel MTU parms [ L:1622 D:1140 EF:110 EB:0 ET:0 EL:3 ] Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client' Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server' TCP/UDP: Preserving recently used remote address: [AF_INET]1.1.1.1:1111 Socket Buffers: R=[42080->42080] S=[57344->57344] UDPv4 link local (bound): [AF_INET]2.2.2.2:0 UDPv4 link remote: [AF_INET]1.1.1.1:1111 MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock MANAGEMENT: CMD 'status 2' MANAGEMENT: CMD 'quit' MANAGEMENT: Client disconnected [UNDEF] Inactivity timeout (--ping-restart), restarting TCP/UDP: Closing socket SIGUSR1[soft,ping-restart] received, process restarting Restart pause, 20 second(s) -
In Kürze:
- Shared Key Tunnel einrichten zwischen dem Server und der pfSense
- bei pfSense als Client einrichten
- In der Konfiguration kein Remote Netz bei Tunnelkonfiguration auf pfSense definieren -> damit dann kein default-route oder route push
- auf pfSense sollte in Routing Table dann nur das Transfernetz auftauchen
- auf OVPN Server Seite mit IPTables (oder Filter der Wahl) NAT aufsetzen so dass alles was über den Tunnel zur pfSense kommt mit der IP des OVPN Server maskiert wird -> somit finden die Pakete auch problemlos ihren Rückweg wieder
- eingehend Firewall Regeln auf pfSense auf OpenVPN Interface nicht vergessen
-
Dem Log entnehme ich, dass er sich eigentlich verbindet, aber wegen Inactivity timeout die Verbindung wieder schließt, sprich: keine Pakete durch den Tunnel gehen.
Auf anhieb kommen mir die Werte für link-mtu und tun-mtu recht hoch vor. Für gewöhnlich bewegen sich die Werte zwischen 1300 und 1400.
Bei meinem pfSense Client habe ich "Peer to Peer (SSL/TLS)" Vorlage aus der Gui gewählt und im Grunde nur IP, Port, Zertifikate und Algorithmen passend zum Server eingetragen.
In den custom options stehen dann noch:
tun-mtu 1372
mssfix 1332
remote-cert-tls serverDie Werte für MTU und MSS habe ich anhand der Ping-Methode "errechnet". Als Start kann man es mit mssfix 1300 mal ausprobieren, wenn die Verbindung dann klappt, hat man den Fehler schon gefunden und kann dann einen größeren Wert austeste.
-
@Libratix said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:
Bei meinem pfSense Client habe ich "Peer to Peer (SSL/TLS)" Vorlage aus der Gui gewählt und im Grunde nur IP, Port, Zertifikate und Algorithmen passend zum Server eingetragen.
Nope. Einfach wie oben beschrieben einen Shared Key Tunnel nutzen. Einfachste Vorgehensweise. P2P TLS kann problematisch sein, weil es hier kein definierter Partner besteht, sondern es ggf. mehrere eingewählte Tunnelendpunkte geben kann. Daher ist bspw. auch bei Protokollen wie OSPF der P2P TLS Mode nicht möglich, sondern NUR der SharedKey Mode.
An irgendwelchen MTUs einfach rumzudrehen ohne Not würde ich ebenfalls nicht. Wenn es nicht läuft, OK, andernfalls unnötig wenn alle Peers ordentlich routen. Kein Grund das auf irgendwelche 1300er Werte runterzudrücken wenn es nicht sein muss.
Dem Log entnehme ich, dass er sich eigentlich verbindet, aber wegen Inactivity timeout die Verbindung wieder schließt, sprich: keine Pakete durch den Tunnel gehen.
Keine Pakete durch den Tunnel sind kein Argument. OVPN im P2P Mode baut nicht einfach den Tunnel ab weil grade nichts durch läuft. Inactivity Timeout auf Client Seite wird getriggert, wenn die Gegenseite nicht (mehr) antwortet und damit angenommen wird, dass die Verbindung abgerissen ist.
-
Oh, sag das mal meinem OSPF, dass er mit P2P TLS nicht möglich ist. Der weiß das offenbar noch nicht.
Und bei mir konnte ich die Inactivity Timeouts eben durch Anpassung der MTU an die realen Umstände beheben.
-
Ehm, ich entnehme eurer Konversation also jetzt das ich alles richtig gemacht habe und es richtig ist das es nicht läuft?
-
@Libratix said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:
Oh, sag das mal meinem OSPF, dass er mit P2P TLS nicht möglich ist. Der weiß das offenbar noch nicht.
Klar. Keine Ahnung was du noch eingestellt hast, dass es vielleicht geht, aber sobald man mehrere S2S Verbindungen bei P2PTLS hat, sieht der OSPF seine Gegenstellen nicht mehr. Mehrfach nachgestellt und mit Core Switchen und Routern als Gegenstellen schon gehabt. Gerade erst vor einem Monat. Ist BTW auch genau so in der Doku und im Troubleshooting Guide explizit erwähnt. Sollte es durch das neue FRR zufällig jetzt gehen würde ich mich trotzdem nicht drauf verlassen.
Ehm, ich entnehme eurer Konversation also jetzt das ich alles richtig gemacht habe und es richtig ist das es nicht läuft?
Nein, inactivity timeout heißt eben dass er keine Kommunikation mehr bekommt. Hat aber nichts mit "da geht kein Paket mehr drüber" -> kein Traffic - zu tun, sondern dass nichts ankommt, was ankommen SOLL. Zudem hatte ich nicht gesagt, dass es nicht an der MTU liegt, sondern, dass man daran nicht rumfingert wenns keinen Grund gibt. Und normalerweise gibts gerade zu irgendwelchen Datacentern eher keinen Grund - weil da niemand hinter irgendwelchen Modems oder sonstigen Gerätekopplern sitzt, die die MTU verhunzen. Es kann auch an anderen Settings liegen. Muss man eben mal das Logging auf 3 oder 4 hochdrehen und genau mitlesen.
Zudem sollte nach Verbindungsaufbau ja das VPN Gateway (die Gegenstelle) in pfSense auftauchen und somit angepingt werden. Es gibt also normalerweise gar nicht die Situation, dass kein Traffic läuft.
-
Das ist bereits Logging auf 4.
Mehr kommt leider nicht.
Sobald zu Hause bin, werde ich es noch höher einstellen. Vielleicht kommt dann mehr Infos.
-
Nah, 4 ist eigentlich schon genug. Wäre aber sinnvoll ggf. Server und Client Logs aus dem gleichen Zeitraum ggü stellen zu können.
