Gebrückte OpenVPN-Clients ohne Internet? Prüfen Sie die NAT-Regel

Der gebrückte Server läuft, die masquerade-Regel ist vorhanden, und der Browser auf dem Client dreht sich weiter. Alles sieht so aus, als müsste es funktionieren, und genau deshalb geht die erste Stunde in die Prüfung des Tunnels und der Zugangsdaten. Dann lesen Sie den Zähler an der NAT-Regel und finden eine Null, die sich nicht bewegt hat. Eine Regel, die nie ein Paket gezählt hat, hat auch nie eines getroffen, und auf einem gebrückten Server ist der Grund strukturell: Der Client-Verkehr verlässt den Rechner über das virtuelle tap-Gerät, während die Regel die physische Karte nennt, die Sie aus einer älteren Anleitung kopiert haben.

Der Zähler ist der Beweis, nicht der Tabelleneintrag

Regeln, die existieren, und Regeln, die treffen, sind verschiedene Dinge, und der Zähler trennt sie. Listen Sie die NAT-Tabelle mit ausführlichen Zählern auf, und lesen Sie die Zahlen neben jeder Regel, bevor Sie etwas ändern. Ein Zähler, der bei null steht, während Verkehr fließt, bedeutet, dass die Regel übersprungen wurde, so vernünftig ihre Adressen auch aussehen. Ein Zähler, der steigt, während die Verbindung weiterhin scheitert, schickt Sie woandershin: Weiterleitung, Rückweg oder das entfernte Ende.

iptables -t nat -L POSTROUTING -v -n

Lesen Sie zuerst den Zähler neben dem Schnittstellen-Treffer. Ist der Quellbereich richtig und die Ausgangsseite falsch, ist die Korrektur ein Wort in der Regel und keine völlig neue Regel.

Finden Sie den Namen, den der Kernel tatsächlich erfasst

Bestimmen Sie das Tunnelgerät vor dem Schreiben der Regel anhand der Schnittstellenliste und nicht aus dem Gedächtnis. Bei einem gebrückten OpenVPN-Setup ist das Gerät meist eine vom Server erstellte tap-Schnittstelle, und ihr Name gehört zu Ihrer lokalen Konfiguration, ist keine universelle Konstante. Bestätigen Sie, dass es existiert, solange der Tunnel läuft, denn ein Gerät, das erst nach dem Verbinden eines Clients erscheint, lässt einen früheren Test wie ein Regelproblem aussehen.

ip -brief link

Notieren Sie den Namen. Jeder spätere Befehl in dieser Diagnose bezieht sich darauf, und ein Tippfehler hier erzeugt genau denselben Nullzähler wie der ursprüngliche Fehler.

Schreiben Sie die Regel auf das Tunnelgerät um

Richten Sie die Regel auf das Tunnelgerät und behalten Sie den Client-Bereich als Trefferbedingung, damit sie Tunnelverkehr abdeckt und die eigenen Verbindungen des Hosts unangetastet lässt. Setzen Sie Ihren eigenen Bereich und Gerätenamen ein, denn beide Beispiele unten sind Beispiele und keines ist zwischen Installationen übertragbar.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

Prüfen Sie dann die beiden anderen Bedingungen, die dasselbe Symptom verbirgt. Prüfen Sie, ob die Weiterleitung aktiviert ist, und wenn nicht, aktivieren Sie sie in der Konfiguration der Distribution selbst statt mit einem echo, das beim Neustart verschwindet. Lesen Sie auch die Zähler der forward-Kette, und wenn sie den Tunnelverkehr verwirft, erlauben Sie gezielt diese Schnittstelle und lassen Sie die Richtlinie der Kette unverändert.

Die forward-Kette mit Zählern zu lesen kostet einen Befehl und schließt die Hälfte der verbleibenden Möglichkeiten aus, bevor Sie eine weitere Regel anfassen.

Warum die physische Karte nie trifft

Eine Brücke ist ein Software-Switch aus dem tap-Gerät und einer physischen Schnittstelle. Der Frame des Clients betritt diesen Switch und verlässt ihn in Richtung des physischen Netzes als Mitglied der Brücke und nicht als Paket auf der Karte. Deshalb ordnet der Kernel das Paket der Brücke und ihrem Port zu, und deshalb taucht die Karte, an die Sie dachten, im Treffer nie auf. An der physischen Schnittstelle ist nichts kaputt; sie ist einfach nicht das Gerät, das der Kernel diesem Paket zuordnet.

Das nächste Problem, auf das Leute stoßen, kommt aus derselben Struktur: Frame-Filterung auf einer Brücke ist eine eigene Einrichtung gegenüber der IP-Filterung. Wenn die Anforderung eine Beschränkung auf Frame-Ebene ist, gehört sie zur Brückenfilterung und nicht zu einer IP-Tabellenregel.

Beweisen Sie es von Anfang bis Ende, und machen Sie es dann dauerhaft

Bringen Sie einen einzelnen Client hoch und pingen Sie etwas im LAN des Servers an; dieser Weg übt die Weiterleitung ohne jede Übersetzung. Fordern Sie danach etwas Öffentliches an, damit die masquerade-Regel benutzt werden muss, und lesen Sie den Zähler noch einmal: Er sollte sich für diesen Test bewegen und nicht für den vorherigen. Ein Mitschnitt auf dem Tunnelgerät zeigt beides, wo der Frame erscheint und welche Adresse er trägt.

Letzter Schritt: Setzen Sie die funktionierenden Regeln in die Konfiguration, die ein Neustart liest, und notieren Sie den Gerätenamen, den die Brücke dieses Hosts tatsächlich verwendet. Alles von Hand Getippte ist nach einem Neustart weg, und derselbe Fehler kommt zurück, ohne dass etwas bleibt, das ihn erklärt.

Bewegt sich der Zähler nach dem Umschreiben immer noch nicht, vergleichen Sie den Quellbereich in der Regel mit der Adresse, die der Client tatsächlich erhalten hat, denn ein gebrückter Server kann Adressen aus einem Bereich verteilen, den Sie nicht beabsichtigt haben.