Waarom thuis-NAT je VPN-interface niet beschermt

Laptops achter een thuisrouter zonder port forwarding accepteren nog steeds SSH-verbindingen die via de VPN binnenkomen. Dat is geen tegenspraak, want twee verschillende apparaten beoordelen twee verschillende pakketten. De router stuurt het versleutelde transport door, en de host beslist wat er gebeurt met het ontsleutelde pakket dat bij zijn tunnelinterface aankomt. Die twee beslissingen gescheiden houden is de hele oefening.

De router stuurt de tunnel door, de host beoordeelt het pakket

Teken het pad van de externe bron naar de dienst voordat je naar één regel kijkt. Het buitenste deel is het VPN-transport, dat door de router en de gateway wordt afgehandeld. Het binnenste deel begint wanneer het eindpunt de tunnellaag verwijdert en de host een pakket ontvangt dat aan zijn VPN-adres is geadresseerd.

Voeg die twee delen samen en de router krijgt de eer voor een beslissing die de host neemt. Een port-forwardingpagina of een routerlog beschrijft alleen buitenste gesprekken, en geen van beide zegt welk ontsleuteld verkeer de host accepteert. De host past zijn eigen inkomende beleid toe op het binnenste pakket, net als op elk pakket dat bij een interface aankomt. In dat beleid wordt de blootstellingsvraag echt beslecht.

Een wildcard-listener is geen openbare dienst

Op Linux betekent binden aan INADDR_ANY elk lokaal adres, dus een dienst kan antwoorden op een tunnelinterface die hij nooit heeft genoemd. De IP-socketreferentie beschrijft die binding, en het is de moeite waard die te lezen voordat je conclusies uit een listenerlijst trekt. Een wildcard-vermelding is een feit over de socket, geen uitspraak over bereikbaarheid.

De twee regels hieronder zijn dezelfde dienst in twee verschillende bindingen, en het verschil is het hele antwoord op de vraag of de interface ertoe doet. Lees eerst op welk adres de socket zit.

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))

Benoem de regeling die de poort zou kunnen bereiken

Drie regelingen zetten een pakket op die interface, en ze hebben verschillende eigenaren. De juiste benoemen beslist wie een beleid moet wijzigen.

Een browserresultaat met een openbaar uitgaand adres zegt niets over een van de drie, omdat het beschrijft hoe uitgaand verkeer naar buiten gaat en niet wat inkomend verkeer is toegestaan. Werk achterstevoren vanaf de listener en het bronadres in het dienstlog. Als de bron een andere tunnelpeer is, is het gatewaybeleid het interessante document. Als het een vertaald adres is, zoek de vertaling voordat je een regel wijzigt.

Beperk de dienst tot het pad dat je bedoelde

Als SSH alleen vanaf een beheerpad nodig is, schrijf dat pad dan op als bronbereik plus een interface. Beperk daarna de inkomende regels van de host op interface, bestemming en bron in plaats van op netwerknaam, want een naam die privé lijkt kan voor elk adres staan. Houd een route aan voor de persoon die het volgende probleem oplost.

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

Een regel die de tunnelinterface en het beheerbereik noemt, drukt de bedoeling op één plek uit. Vergelijk hem met een regel die voor het Wi-Fi-netwerk is geschreven, die niets zegt over ontsleuteld tunnelverkeer. Als de twee lagen het oneens zijn, is het hostbeleid degene die het pakket tegenkomt.

Laat logins en patches precies waar ze zijn; een poort bereiken was nooit hetzelfde als hem mogen gebruiken. Noteer de adresfamilie en tijd voor elke onbekende bron, en onderzoek voordat je een functie of een kwetsbaarheid de schuld geeft. Een regel die elke tunnelpeer toelaat is een ander ontwerp dan een die een beheersubnet toelaat, en geen logregel zal zeggen welke bedoeld was.

Accepteer de oplossing met één succes en één weigering

Bewijs beide helften: één goedgekeurde verbinding slaagt en één uitgesloten pad wordt geweigerd. De weigering is de helft die mensen overslaan, en het is degene die laat zien dat de regel werk doet in plaats van naast een toestemmende standaardwaarde te staan. Test vanaf de uitgesloten kant in plaats van erover te redeneren.

Herhaal het paar na een herverbinding, want een tunnel die terugkomt met een andere interfacenaam kan stilletjes een regel omzeilen die op de oude is toegespitst. De grens die ertoe doet, is degene die de host toepast op pakketten die hij echt ontvangt.