Der WireGuard-Handshake funktioniert, der Dienst nicht

Ein erfolgreicher Handshake beweist nur den Tunnel. Ein Dienst auf dem VPN-Host braucht weiterhin einen lauschenden Socket, eine Input-Regel und eigene Berechtigungsprüfungen.

Der Handshake läuft durch, der Client zeigt einen frischen Übertragungszähler, und eine Anfrage an einen Dienst auf demselben Server scheitert trotzdem. Diese Kombination verwirrt Leute, weil der Tunnel nachweislich funktioniert. Was nicht bewiesen ist, ist die lokale Zustellung: Das Paket hat den Host erreicht, und der Host muss es noch auf dem richtigen Socket annehmen und an einen Prozess mit Antwortberechtigung übergeben. Arbeiten Sie diese drei Prüfpunkte der Reihe nach durch.

Bleiben Sie bei dem ersten stehen, der nicht zutrifft, und legen Sie für die anderen keine Regeln an.

Der Handshake beweist nur den Tunnel

Der Handshake von WireGuard vereinbart Schlüssel zwischen Peers und autorisiert Verkehr für die Bereiche, die jeder Peer aufgelistet hat. Er sagt nichts darüber, welche Prozesse auf dem Server lauschen, und nichts darüber, ob die Host-Firewall Pakete annimmt, die an eine der eigenen Adressen gerichtet sind.

Genau diese letzte Unterscheidung wird am häufigsten übersehen: Verkehr zum Host selbst ist lokaler Input, während Verkehr, der durch den Host zu einem anderen Ziel läuft, Weiterleitung ist. Sie werden von verschiedenen Firewall-Ketten und verschiedenen Einstellungen behandelt. Die falsche Kette zu prüfen kostet einen Nachmittag und liefert Zähler, die harmlos aussehen.

Lesen Sie Listener und Route

Bestätigen Sie auf dem Client, dass die Tunneladresse des Servers in den Tunnel geroutet wird. Bestätigen Sie auf dem Server, dass ein Socket auf der vom Client genutzten Adresse existiert und dass der Prozess dahinter der gewünschte ist.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Ein Listener auf 127.0.0.1 wird eine an 10.66.0.1 gerichtete Anfrage nie beantworten, egal was die Firewall erlaubt. Ein Listener auf der Wildcard-Adresse wird es, sofern keine Regel ihn blockiert. Die Socket-Liste klärt damit die Hälfte der Fälle, bevor irgendeine Regel betrachtet wird. Port und Adresse entscheiden zusammen, ob eine Anfrage ankommen kann.

Vergleichen Sie die Adresse, die der Client nutzt, mit der Adresse, die der Server tatsächlich auf dem Tunnel-Interface besitzt. Eine veraltete Konfiguration auf einer der Seiten erzeugt eine Anfrage, die korrekt zu einem Peer geroutet wird, der diese Adresse nicht hat.

Setzen Sie Regeln für lokalen Input, nicht für Weiterleitung

Kommt das Paket an und existiert der Socket, ist die verbleibende Grenze die Input-Policy. Eine Regel, die Weiterleitung erlaubt, erlaubt keine lokale Zustellung, und eine auf ein Interface begrenzte Regel passt möglicherweise nicht auf den erwarteten Namen des Tunnel-Interface.

Testen Sie mit einem einzelnen erlaubten Port zum gewünschten Dienst, statt den Host zu öffnen. Prüfen Sie dann die eigene Autorisierung der Anwendung: eine Allowlist, eine Kontopflicht oder die Bindung an einen bestimmten Hostnamen kann eine Anfrage ablehnen, die das Netzwerk erfolgreich zugestellt hat.

Lassen Sie Zertifikatsprüfungen an. Eine unerwartete Zertifikatsidentität ist eine Information darüber, welcher Host geantwortet hat, kein Hindernis zum Umgehen. Wegklicken verdeckt den einzigen Hinweis, der den falschen Dienst identifiziert.

Trennen Sie Namens-, Größen- und Identitätsfehler

Ein Dienst, der per Adresse funktioniert, per Name aber scheitert, ist ein DNS-Problem, und die Korrektur gehört in die Resolver-Konfiguration, die an den Client ausgeliefert wird, nicht in die Firewall. Ein Dienst, der kleine Anfragen beantwortet, bei größeren Antworten aber stockt, deutet auf Paketgröße und MTU hin, was eine ganz andere Untersuchung ist.

Ein HTTPS-Fehler mit dem falschen Hostnamen bedeutet meist, dass die Anfrage einen anderen Dienst erreicht hat, oft weil ein Proxy oder ein anderer Listener diesen Port besitzt. Lesen Sie den Betreff des Zertifikats und vergleichen Sie ihn mit dem Host, den Sie erreichen wollten. Dieser Vergleich kostet nichts und beendet die Untersuchung oft.

Notieren Sie, welcher Prüfpunkt versagt hat: Socket, Input-Regel oder Anwendungsrichtlinie. Diese eine Zeile unterscheidet einen Netzwerkfehler von einer Autorisierungsentscheidung. Sie hindert auch die nächste Person daran, Ports zu öffnen, die nie das Problem waren.

Ähnliche Artikel