Warum Heim-NAT Ihre VPN-Schnittstelle nicht schützt

Laptops hinter einem Heimrouter ohne Portweiterleitung nehmen weiterhin SSH-Verbindungen an, die über das VPN eintreffen. Das ist kein Widerspruch, denn zwei verschiedene Geräte beurteilen zwei verschiedene Pakete. Der Router leitet den verschlüsselten Transport weiter, und der Host entscheidet, was mit dem entschlüsselten Paket geschieht, das an seiner Tunnelschnittstelle ankommt. Diese beiden Entscheidungen auseinanderzuhalten ist die ganze Übung.

Der Router leitet den Tunnel weiter, der Host beurteilt das Paket

Skizzieren Sie den Weg von der entfernten Quelle zum Dienst, bevor Sie eine einzige Regel ansehen. Der äußere Abschnitt ist der VPN-Transport, den Router und Gateway abwickeln. Der innere Abschnitt beginnt, sobald der Endpunkt die Tunnelschicht abstreift und der Host ein Paket erhält, das an seine VPN-Adresse adressiert ist.

Fassen Sie diese beiden Abschnitte zusammen, und der Router bekommt Anerkennung für eine Entscheidung, die der Host trifft. Eine Portweiterleitungsseite oder ein Routerprotokoll beschreibt nur äußere Gespräche, und keines sagt, welchen entschlüsselten Verkehr der Host annimmt. Der Host wendet seine eigene Eingangsrichtlinie auf das innere Paket an, so wie auf jedes Paket, das an einer Schnittstelle eintrifft. In dieser Richtlinie wird die Frage der Exposition tatsächlich entschieden.

Ein Wildcard-Listener ist kein öffentlicher Dienst

Unter Linux bedeutet das Binden an INADDR_ANY jede lokale Adresse, sodass ein Dienst auf einer Tunnelschnittstelle antworten kann, die er nie benannt hat. Die IP-Socket-Referenz beschreibt diese Bindung, und sie lohnt sich zu lesen, bevor Sie aus einer Listener-Liste Schlüsse ziehen. Ein Wildcard-Eintrag ist eine Tatsache über den Socket, keine Aussage über Erreichbarkeit.

Die beiden Zeilen unten sind derselbe Dienst in zwei verschiedenen Bindungen, und der Unterschied ist die ganze Antwort darauf, ob die Schnittstelle zählt. Lesen Sie zuerst, auf welcher Adresse der Socket sitzt.

ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))

Benennen Sie die Anordnung, die den Port erreichen könnte

Drei Anordnungen bringen ein Paket auf diese Schnittstelle, und sie haben verschiedene Eigentümer. Die richtige zu benennen entscheidet, wer eine Richtlinie ändern muss.

Ein Browserergebnis mit einer öffentlichen Ausgangsadresse sagt nichts über eine der drei aus, denn es beschreibt, wie ausgehender Verkehr hinausgeht, statt was eingehendem Verkehr erlaubt ist. Arbeiten Sie stattdessen rückwärts vom Listener und der Quelladresse im Dienstprotokoll. Ist die Quelle ein anderer Tunnel-Peer, ist die Gateway-Richtlinie das interessante Dokument. Ist es eine übersetzte Adresse, finden Sie die Übersetzung, bevor Sie eine Regel ändern.

Begrenzen Sie den Dienst auf den beabsichtigten Pfad

Wenn SSH nur von einem Verwaltungspfad aus nötig ist, schreiben Sie diesen Pfad als Quellbereich plus Schnittstelle auf. Begrenzen Sie dann die Eingangsregeln des Hosts nach Schnittstelle, Ziel und Quelle statt nach Netzwerknamen, denn ein Name, der privat aussieht, kann für jede Adresse stehen. Halten Sie eine Route für die Person bereit, die das nächste Problem löst.

nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input

Eine Regel, die die Tunnelschnittstelle und den Verwaltungsbereich nennt, drückt die Absicht an einer Stelle aus. Vergleichen Sie sie mit einer Regel für das WLAN, die nichts über entschlüsselten Tunnelverkehr sagt. Wenn die beiden Schichten nicht übereinstimmen, ist die Host-Richtlinie die, auf die das Paket trifft.

Lassen Sie Anmeldungen und Patches genau dort, wo sie sind; einen Port zu erreichen war nie dasselbe wie ihn nutzen zu dürfen. Notieren Sie Adressfamilie und Uhrzeit jeder unbekannten Quelle, und untersuchen Sie, bevor Sie eine Funktion oder eine Schwachstelle beschuldigen. Eine Regel, die jeden Tunnel-Peer zulässt, ist ein anderes Design als eine, die ein Verwaltungssubnetz zulässt, und keine Protokollzeile sagt, welches gemeint war.

Abnehmen mit einem Erfolg und einer Ablehnung

Beweisen Sie beide Hälften: eine genehmigte Verbindung gelingt und ein ausgeschlossener Pfad wird abgelehnt. Die Ablehnung ist die Hälfte, die man überspringt, und sie zeigt, dass die Regel arbeitet, statt neben einer erlaubenden Voreinstellung zu stehen. Testen Sie von der ausgeschlossenen Seite, statt darüber nachzudenken.

Wiederholen Sie das Paar nach einer Neuverbindung, denn ein Tunnel, der mit einem anderen Schnittstellennamen zurückkehrt, kann eine Regel, die auf die alte begrenzt ist, stillschweigend umgehen. Die Grenze, auf die es ankommt, ist die, die der Host auf Pakete anwendet, die er tatsächlich erhält.