OPNsense Forum
International Forums => German - Deutsch => Topic started by: superwinni2 on May 25, 2021, 11:37:22 am
-
Hallo zusammen
weiß jemand wie der "Best Practice" Fall zu konfiguration mit OpenVPN und MultiWAN aussieht?
Ich würde gerne einen einzelnen Server beibehalten, diesen jedoch von 2 verschiedenen (externen) Interfaces ansprechen. Hierzu habe ich aktuell eine Portweiterleitung von der fixen WAN2 IP auf die fixe WAN1 IP gemacht.
Wenn meine Theorie stimmt, dann sollte ja bei deaktiviertem WAN2 weiterhin die WAN 1 funktionieren und bei ausgefallenem WAN1 die Portweiterleitung greifen oder?
-
Definiere Best Practice :) Es gibt immer verschiedene Szenarien, je nachdem was man erreichen möchte. Was ist denn die konkrete Ausgangslage?
> Ich würde gerne einen einzelnen Server beibehalten, diesen jedoch von 2 verschiedenen (externen) Interfaces ansprechen. Hierzu habe ich aktuell eine Portweiterleitung von der fixen WAN2 IP auf die fixe WAN1 IP gemacht.
Öh warum so umständlich? Warum nicht einfach den OVPN Server auf localhost binden und auf beiden WANs schlicht ein Forwarding auf "localhost" machen? Ein Forward von WAN2 auf WAN1 IP klingt eher suboptimal und fehleranfällig wenn WAN1 down geht und die IP verliert.
Konfiguration mit localhost funktioniert generell auf den *Sensen ganz fein, da localhost "immer" da ist und dementsprechend es eigentlich keinen Grund gibt, den VPN Server neu zu starten wenn ein WAN down geht. Dadurch bleibt der Service ansprechbar und du kannst via Redirects von WAN1/WAN2 drauf ohne Probleme zugreifen und die Einstellungen etc. bleiben ganz die Selben.
Cheers
\jens
-
Definiere Best Practice :) Es gibt immer verschiedene Szenarien, je nachdem was man erreichen möchte. Was ist denn die konkrete Ausgangslage?
Ziel sollte sein so viel wie möglich "Hochverfügbar" zu machen.
Wir haben 2 WAN Leitungen von 2 ISP.
WAN 1 ist ein /28 Netzwerk (200/200 MBit/s)
WAN2 ist nur eine einzelne IP (100/40 MBit/s)
Beides Businessanschlüsse. Leider hat WAN2 eben nur eine IP. Wird sich vermutlich auch nicht so schnell ändern. Ist theoretisch ein Relikt aus der Vergangenheit aber lieber haben statt brauchen.
Ist Situation auf OPNsense:
Routing:
Standartmäßig sollte alles via WAN1 geroutet werden. Bestimmte Regeln sollen via WAN2 routen.
Fällt ein WAN aus soll das andere übernehmen. Kein Loadbalancing. Am besten wäre wenn keiner etwas davon mitbekommt bzw (Das dies nicht komplett geht mit aktuellen Verbindungen ist mir klar.)
Hierzu habe ich bereits die Gateways eingerichtet, beide als Upstream markiert und die Gewichtung 100 auf WAN1 und 200 auf WAN2 gesetzt.
Ebenso für die einzelnen Regeln (welche WAN2 priorisieren sollen) eine GW-Gruppe angelegt.
Meiner Meinung nach sollte ich nur die GW-Gruppe bei entsprechenden Regeln hinzufügen.
Fällt WAN1 aus so wird das Default Gateway geändert und es läuft alles über WAN2.
Fällt WAN2 aus, so wird in der GW-Gruppe Tier 2 aktiviert und der Traffic für die entsprechenden Regeln läuft über WAN1.
IPsec:
Wir haben 3 verschiedene Site2Site Verbindungen über WAN1. (2 davon werden zukünftig mit OPNsense unterwegs sein)
Ist hier irgendwas möglich in Sinne von "wenn WAN1 ausfällt nehme WAN2 zur Verbindung"?
HAProxy:
Dann habe ich noch einen HAProxy am laufen. Gewünscht wäre diesen ebenfalls "Hochverfügbar" zu machen... Jedoch läuft mein OpenVPN bereits über TCP Port 443. Daher wird dies vermutlich nichts werden. Habe bereits ein bisschen mit TCP Frontend im HAProxy probiert. Bin aber bisher noch zu keinem zufriedenstellendem Ergebnis gekommen. Vielleicht benötigt es noch etwas Feinschliff.
OpenVPN:
Öh warum so umständlich? Warum nicht einfach den OVPN Server auf localhost binden und auf beiden WANs schlicht ein Forwarding auf "localhost" machen? Ein Forward von WAN2 auf WAN1 IP klingt eher suboptimal und fehleranfällig wenn WAN1 down geht und die IP verliert.
Sehr schicke Idee. Warum bin ich da nicht drauf gekommen :)
Öffentlicher DNS Server (bind) für LetsEncrypt:
Hier würde ich analog zur OpenVPN Variante vorgehen.
LetsEncrypt:
Da ich alles via DNS-01 Challenge mache ist hier die IP Adresse egal.
Gruß
Gesendet von meinem OnePlus 8t mit Tapatalk
-
> Wir haben 3 verschiedene Site2Site Verbindungen über WAN1. (2 davon werden zukünftig mit OPNsense unterwegs sein)
> Ist hier irgendwas möglich in Sinne von "wenn WAN1 ausfällt nehme WAN2 zur Verbindung"?
Nope. Da hilft dir nur den Kram auf OpenVPN oder Wireguard umzubauen. Und Wireguard hat wieder ganz andere Problemchen mit MultiWAN/CARP etc. bzw. wird dann schnell komplex. OpenVPN wäre da am Besten. Mit IPsec bekommst du wegen der Policies etc. kein einfaches "Failover" hin.
OpenVPN wäre da recht einfach nutzbar und die Client->Server Strecke kann durch multiple Remotes eben recht einfach einen Failover machen. Sprich 2 remote Statements in der Client Config -> Wenn WAN1 ausfällt wird versucht wieder aufzubauen, dann WAN2 IP versucht, Tunnel steht. Lediglich wenn WAN1 wieder da ist, wäre der Failback "manuell", weil der stehende Tunnel nicht einfach abgebaut wird um den wieder über WAN1 aufzubauen.
Alternativ: 2 OVPN Tunnel bauen (Client zu WAN1/2) und ohne Remote Networks konfigurieren (also quasi nur ein Transfernetz /30 aufbauen zwischen den Standorten) und dann beide GWs jeweils auf jeder Seite in eine Failover Group reinpacken mit Prio auf dem WAN1 XFER Netz. Dann mit policy based rules den Traffic auf die anderen Seite wuppern. Dann sollte entsprechend der Traffic über die WAN1 mit Prio laufen und ansonsten via WAN2 Tunnel tuckern.
Die Alternative sollte/könnte auch mit IPsec VTI (routed) funktionieren. Braucht dann aber wie gesagt 2 Tunnel wie bei OVPN und dann eine GW Gruppe.
"Automatisieren" statt Failover Gruppe wäre auch denkbar aber komplex. Möglich dann via FRR+OSPF zu konfigurieren. Dazu wären dann entweder die beiden IPsec oder OVPN GWs der entsprechenden Tunnel die beiden "Gegenstellen" im OSPF und auf der anderen Seite ebenso. Dann mit Gewichtung im OSPF die WAN1-Tunnel-Line priorisieren und die Netze entsprechend der anderen Seite darüber announcen. Das geht dann auch bei Down eines Tunnels recht schnell bis OSPF das GW down meldet und den Traffic über die 2. Line umroutet.
HAproxy wird wie du sagst schwer, wenn tcp/443 schon belegt ist. Zudem ändern sich ja die externen IPs die erreichbar sind je nachdem ob WAN1 oder WAN2. Da würde nur ein vorgeschalteter (Cloud) Loadbalancer Sinn machen, der beide Endpunkte (WAN1/WAN2) konfiguriert hat helfen. Müsste man bspw. bei Cloudflare o.ä. anmieten und konfigurieren.
Cheers
\jegr
-
Nope. Da hilft dir nur den Kram auf OpenVPN oder Wireguard umzubauen.
So wichtig sind die Verbindungen dann auch nicht um das "Keep it Simple" Prinzip aktuell aufzubrechen.
Wenn wir wissen, dass der Ausfall von längerer Natur ist, dann wird eben kurzerhand auf beiden Seiten die Config von Hand geändert.
Wäre aber ein kleines Projekt für die Zukunft um auch noch das letzte etwas an Hochverfügbarkeit rauszuholen.
Mit dem HAProxy muss ich mir noch einen guten MasterPlan ausdenken.. Vielleicht auch etwas in der Art von "Auf Localhost" lauschen lassen, Portforwarding einrichten und hoffen dass ich den Traffic zwischen OpenVPN und HTTP*S unterscheiden kann. (Webseiten via SNI und VPN via IP oder so)
Danke schonmals und Gruß
-
Oder nicht tcp/443 verwenden für den OpenVPN via TCP. Oder sowas wie sslh vornedran packen und dort OpenVPN / HTTPS trennen und dann aufteilen.
-
Eine IP, teilweise HTTPS, teilweise TCP (OpenVPN)
Kurze Notizen für alle die das gleiche Vorhaben...
Ich habe es komplett mit dem Internen HAProxy geschafft.
Kurzform als Text:
Ich werde die Pakete in Layer 4 annehmen und je nachdem ob ein SSL Handshake stattfindet oder nicht den Traffic entsprechend leiten. Wenn kein Handshake stattfindet wird das Backend "OpenVPN" genommen. Wenn ein Handshake stattfindet wird der Traffic in eine weiteres Frontend weitergeleitet jenes im Layer7 läuft und HTTP(S) Befehle verarbeiten kann.
Damit dies reibungslos funktioniert muss auf dem Layer 4 Frontend besondere Einstellungen getroffen werden.
Habe 2 Frontends angelegt:
- 203.0.113.1:443
- 127.0.0.1:8765
Frontend 203.0.113.1:443
Type: TCP
Default Backend: None
Enable SSL offloading: Deaktiviert
Option pass-through:
tcp-request inspect-delay 3s
tcp-request content accept if HTTP
Select Rules:
Backend OpenVPN
Interne Weiterleitung
Frontend 127.0.0.1:8765
Dieses Frontend wie ein "gewöhnliches" Frontend einrichten.
Regeln:
Backend OpenVPN
IF NICHT (negierung aktiv!) "Traffic is SSL (TCP request content inspection)" dann benutze Backend "OpenVPN"
Interne Weiterleitung
IF "Traffic is SSL (TCP request content inspection)" benutze Backend 127.0.0.1:8765