Ein öffentlicher Host für VPN und Web: So trennt man die Rollen

Eine Maschine kann alle drei Bedürfnisse gleichzeitig erfüllen: Tunnel beenden, HTTPS beantworten und zwischen zwei privaten LANs weiterleiten. Ob das sinnvoll ist, hängt an drei Dingen, die Sie auf Papier klären können: wer die öffentliche Adresse besitzt, wer jedes Port- und Protokollpaar besitzt und welcher Prozess Pakete weiterleiten darf. Machen Sie das richtig, ist der geteilte Host nichts Besonderes. Machen Sie es falsch, verbringen Sie ein Wochenende mit einem Dienst, der sauber startet und nie antwortet.

Was folgt, ist ein Entscheidungsverfahren, kein Bauplan. Jeder Schritt endet mit der Prüfung, die beweist, dass die gerade hinzugefügte Rolle wirklich isoliert ist.

Wählen Sie den Eigentümer der Adresse vor den Ports

Ein Tunnelendpunkt und ein Webserver können sich einen Kernel teilen; sich gleichzeitig eine Adresse, einen Port und ein Protokoll zu teilen, ist das, was scheitert. WireGuard belegt meist UDP 51820, OpenVPN belegt UDP 1194 oder TCP 443, und ein Webserver belegt TCP 443. Das schmerzhafte Paar ist OpenVPN über TCP 443 neben HTTPS, weil beide denselben Socket wollen und der Kernel ihn dem gibt, der zuerst gebunden hat. Nur ein Demultiplexer davor, etwa sslh oder ein TLS-fähiger Proxy, lässt beide diesen Port teilen, und er fügt eine Komponente hinzu, deren Ausfall genau wie ein Firewallproblem aussieht.

Sehen Sie sich die Eigentümer an, bevor Sie etwas ändern: ss -lntup druckt lokale Adresse, Port und Prozess für jeden lauschenden Socket. Zwei Zeilen mit 0.0.0.0:443 bedeuten, dass der zweite Dienst nie gebunden hat, so fröhlich sein Init-Skript auch war. Bridging verschiebt ebenfalls den Eigentümer. Wenn eth0 zu br0 wird, wandert die IP auf br0 und jede Firewallregel, die eth0 nennt, passt nicht mehr, also binden Sie Dienste an die Bridge und prüfen es mit ip -br addr.

Dieselbe Eigentumsregel erklärt eine Überraschung, die bei virtuellen Maschinen auftaucht. Ein Tunnelserver, der in einem Gast im selben LAN läuft, behält die Adresse des Gasts, sodass Verbindungen an die eigene Adresse des Hosts auf dem Host bleiben und der Tunnel des Gasts sie nie sieht, was auch immer das Clientprofil nahelegt.

Routen Sie zwischen den beiden LANs oder NATen Sie eine Seite

Zwei LANs, die sich nicht sehen, können jeweils den öffentlichen Host anwählen, der dann zwischen den Tunneln weiterleitet. Dieses geroutete Design braucht drei Dinge: eingeschaltete Weiterleitung, eine Route zu jedem entfernten Präfix und eine Weiterleitungsrichtlinie, die den Transit durchlässt. sysctl -w net.ipv4.ip_forward=1 deckt das erste ab, ip route add 10.20.0.0/24 dev wg1 das zweite, und eine nftables-Zeile wie nft add rule inet filter forward iifname "wg0" oifname "wg1" accept das dritte.

Source-NAT ist leichter anzubauen und schwerer zu debuggen. Masquerading schreibt die Clientadresse um, sodass die Gegenseite den Hub statt des echten Hosts sieht und ihre Zugriffsregeln und Logs für die Zuordnung unbrauchbar werden. Wenn beide Netze Ihnen gehören, routen Sie. Wenn eine Seite einem Dritten gehört, der keine Rückroute hinzufügt, ist NAT die Option, die diese Woche ausgeliefert wird. Schreiben Sie in jedem Fall den Adressplan auf, denn zwei überlappende /24 lassen sich mit noch so viel Konfiguration nicht routen.

Nichts daran, als Internetausgang für ein Laptop zu dienen, hindert dieselbe Kiste daran, eingehende Tunnel zu beenden. Nur überlappende Adressen tun das, weshalb der Adressplan das Dokument ist, auf das es ankommt.

Testen Sie die Trennung, während zwei Rollen gestoppt sind

Der nützliche Test ist Subtraktion: Stoppen Sie zwei Rollen und bestätigen Sie, dass die dritte weiter antwortet. Eine Webanfrage sollte mit abgeschaltetem Tunneldienst durchlaufen, und ein Tunnel-Handshake sollte mit gestopptem Webserver durchlaufen. Wenn beides nur funktioniert, wenn alles läuft, haben Sie eine zufällige Abhängigkeit: eine gemeinsame Firewalltabelle, eine verirrte Route oder einen Namen, der auf die falsche Adresse zeigt.

Drei Befehle machen diesen Test konkret. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ beweist, dass der lokale Listener ohne externes DNS antwortet, wg show auf dem Client beweist, dass der Handshake abgeschlossen wurde, und tcpdump -ni any port 51820 auf dem Hub trennt ein Routingproblem von einem Schlüsselproblem. Ein Handshake, der im Mitschnitt nie auftaucht, ist vor dem Host gestorben: Provider-Firewall, falsche öffentliche Adresse oder eine NAT-Regel unterwegs.

Wiederholen Sie die Subtraktion für die weitergeleiteten LANs. Mit einem getrennten Peer sollte ein Ping über den Hub scheitern; nach dem Wiederverbinden sollte er sich erholen, ohne eine Regel anzufassen. Ein Ping, der sich erst nach einem Neustart des Tunnels erholt, deutet auf Richtlinie statt Erreichbarkeit hin, und das ist eine andere Korrektur.

Halten Sie das Regelwerk lesbar, während Sie Rollen subtrahieren. nft list ruleset sollte eine Accept-Regel pro Richtung zeigen, die Sie wirklich brauchen, und eine Forward-Kette, die alles akzeptiert, ist keine Trennung, sondern eine funktionierende Demo.

Zugangsleitungen nur mit IPv6 und IPv4-Dienste

Manche Zugangsleitungen liefern nur IPv6-Erreichbarkeit, und Dienste müssen trotzdem über IPv4 veröffentlicht werden. Der Tunnel selbst reist über die Familie, die noch Verkehr durchlässt, während der veröffentlichte Dienst auf einer Adresse im Tunnel sitzt. Das kehrt die übliche Annahme um und bricht still das Monitoring: eine Firewallregel oder Uptime-Prüfung, die für den IPv4-Pfad geschrieben wurde, beobachtet jetzt eine Schnittstelle, die nichts trägt.

Testen Sie jede Familie für sich mit curl -4 und curl -6, denn eine erfolgreiche Anfrage sagt nichts über den Pfad aus, den Sie nicht probiert haben. Porteigentum ändert sich nicht zwischen Familien, der Listener schon: ss -lntup listet IPv4- und IPv6-Sockets als getrennte Zeilen, und 0.0.0.0:443 deckt [::]:443 nicht ab, es sei denn, der Prozess hat einen Dual-Stack-Socket angefordert.

Ein Dienst, der auf einer Familie antwortet und auf der anderen ablehnt, ist meist ein Listenerproblem, kein Routingproblem. Bevor Sie das Design für fertig erklären, bestätigen Sie, dass jede Rolle ihre eigene Adresse oder ihren eigenen Port besitzt, dass Weiterleitung aktiviert und erlaubt ist und dass jede Rolle noch antwortet, während die anderen beiden gestoppt sind.