Waarom het adres van je VPN-tunnel geen inkomende poort opent
Een tunneladres identificeert je client bij peers die erheen kunnen routeren, en maakt nooit een luisteraar. Controleer de binding, de retourroute en daarna het beleid.
Maak verbinding met de VPN van kantoor, start een kleine dienst op poort 8443, stuur het tunneladres naar een collega en zie de verbinding mislukken terwijl de client nog steeds meldt dat hij verbonden is. Niets is stuk in de tunnel: het adres is uitgegeven, de sessie staat, en de pakketten die het antwoord zouden dragen worden simpelweg nooit toegelaten. Werk de drie controles hieronder in volgorde af en stop bij degene die mislukt, want elk heeft een andere oplossing en slechts één ervan gaat over de VPN.
Begin bij waar de socket werkelijk aan gebonden is
Voordat er iets gerouteerd wordt, moet er iets luisteren op een adres dat de aanroeper kan bereiken. Ontwikkelservers zijn de gebruikelijke boosdoener, omdat veel ervan standaard aan loopback binden en alleen verbindingen accepteren die van dezelfde machine komen. Een tunneladres verandert die binding niet, en het besturingssysteem zal de verbinding weigeren lang voordat de VPN erbij betrokken is.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Lees de kolom met het lokale adres in plaats van de status. 127.0.0.1:8443 betekent alleen loopback, en de oplossing is een binding op 0.0.0.0 of op het tunneladres zelf. 0.0.0.0:8443 accepteert op alle interfaces, wat ruimer is dan de meeste mensen bedoelen wanneer de machine ook een openbaar adres heeft; 10.64.7.15:8443 is de smalle versie die alleen luistert waar de collega kan komen. Let ook op de procesnaam in dezelfde uitvoer, want een achtergebleven instantie van een eerdere test is een veelvoorkomende reden dat de poort open lijkt en met de verkeerde inhoud antwoordt.
Vraag dan of iets naar dat adres kan routeren
Een tunneladres is alleen zinvol voor peers die geconfigureerd zijn om dat prefix de tunnel in te sturen. De machine van de collega heeft zijn eigen tabel, en zonder een route naar het tunnelsubnet gaat het pakket naar de standaardgateway en sterft het op een plek die geen idee heeft dat het adres bestaat. Dat is een routeringsvraag aan de kant van de aanroeper, geen toestemming aan jouw kant.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
De server tussen de twee clients is net zo belangrijk. In het gebruikelijke ontwerp voor toegang op afstand opent elke client een uitgaande verbinding naar de gateway en de gateway houdt de status van die stromen bij, zodat antwoorden terugkomen over een pad dat hij al kent. Een verbinding van de ene client naar de andere is een nieuwe stroom die de gateway moet accepteren en doorsturen, en veel implementaties schakelen dat bewust uit om clients van elkaar geïsoleerd te houden. Consumenten-VPN-diensten isoleren meestal standaard; bedrijfsgateways staan het soms per groep toe.
Controleer de richting voordat je iets op de host verandert. Als het tunneladres antwoordt vanaf de gateway zelf maar niet vanaf een peer, is de client-naar-client-instelling van de gateway het verschil, en geen enkele aanpassing van de lokale firewall kan dat vervangen.
Vind ten slotte het beleid dat de stroom toestaat
Drie beleidslagen liggen tussen een gerouteerd pakket en een dienst die antwoordt: de doorstuur beslissing van de VPN-server, de firewall van de host en elke cloudbeveiligingsgroep voor de instantie. Alle drie moeten het eens zijn, en ze falen op verschillende manieren, daarom is het symptoom in de tabel hierboven nuttiger dan de foutmelding in de browser.
De firewall van de host is de laag die mensen na een geslaagde binding vergeten, omdat een regel die de poort op de LAN-interface toestaat hem niet automatisch op de tunnelinterface toestaat. Interfacegebonden regels zijn correct ontwerp en ook de gebruikelijke oorzaak van een dienst die vanaf kantoor werkt en vanaf huis niet. Lees de reikwijdte van de regel, niet het poortnummer.
Stateful filtering verklaart het omgekeerde geval. Een uitgaande verbinding vanaf je laptop maakt status aan, en antwoorden daarop worden toegelaten zonder inkomende regel. De verbinding van de collega is een volledig nieuwe stroom zonder status erachter, dus die heeft een uitdrukkelijke toestemming nodig. Die asymmetrie is de hele reden dat een werkende browsersessie op je eigen machine niets zegt over of de dienst van buitenaf bereikbaar is.
Als één controle mislukt, verander dan het ontwerp en niet de tunnel
Als de eis is dat een collega je lokale dienst opent, is het eerlijke antwoord meestal een mechanisme dat voor inkomende toegang is gebouwd. Een omgekeerde SSH-tunnel is de kleinste: je machine verbindt uitgaand naar een host die de collega al kan bereiken, en de luisteraar bestaat op die host.
ssh -N -R 8443:127.0.0.1:8443 [email protected]De relay heeft GatewayPorts clientspecified nodig in zijn SSH-serverconfiguratie, anders bindt de doorgestuurde luisteraar op de relay aan loopback en krijgt de collega dezelfde weigering als voorheen. Voor alles wat langer duurt dan een middag is een loadbalancer of ingress met healthcheck en certificaat voor de gepubliceerde naam het betere instrument, en een site-naar-site-tunnel met routes voor beide subnetten is het juiste antwoord wanneer twee netwerken echt met elkaar moeten praten.
Elk van die ontwerpen maakt de blootstelling expliciet, en dat is het punt. Een VPN verplaatst pakketten tussen netwerken waarvoor je al gemachtigd was; hij publiceert geen dienst en maakt van een laptop geen host die naar het internet is gericht. De taak is beslissen welke van de drie lagen je verandert, en de tunnel is zelden een daarvan.