Inkomende VPN in Windows of een OpenVPN-host: kies in vijf minuten

Windows kan een VPN-verbinding accepteren zonder dat er iets anders dan het besturingssysteem is geïnstalleerd, en dat helpt echt wanneer twee machines die je bezit een middag lang een tunnel nodig hebben. Het blijft ongeveer zo lang bruikbaar. De ingebouwde listener heeft een vast protocolmenu, geen beleid per client en een afhankelijkheid van een desktop die iemand kan sluiten. De keuze tussen hem, een router-eindpunt en een OpenVPN-host komt neer op drie voorwaarden, niet op voorkeur.

Wat de ingebouwde listener werkelijk is

De wizard voor inkomende verbindingen maakt van een werkstation een klein eindpunt voor toegang op afstand. Je kiest welke lokale accounts mogen inbellen, hoe adressen worden uitgegeven en welk protocol aan staat: PPTP, plus L2TP/IPsec of SSTP waar de editie en het certificaatwerk die ondersteunen.

Wat hij niet is, is een beleidslaag. Er is geen routetoewijzing per gebruiker, geen door de server afgedwongen split tunnel en geen scheiding tussen de tunnel en de eigen netwerkidentiteit van het werkstation. Een client die verbindt, landt op hetzelfde segment als het werkstation, onder de firewallregels van dat segment.

Juist dat laatste punt moet worden gewogen. De eigen poorten, shares en browser van het werkstation zijn nu bereikbaar voor iedereen die het account heeft, en het account is een lokaal Windows-account met al het andere dat het al kan.

Drie voorwaarden die het beslissen

Vraag hoe lang de toegang moet duren, hoeveel mensen hem nodig hebben en of het netwerk het protocol überhaupt kan leveren.

Als het antwoord één machine, één persoon en een paar uur is op een netwerk waar jij de router beheert, is de ingebouwde listener in verhouding. Als toegang een maand lang herstarts moet overleven, vijf collega's met aparte inloggegevens moet bedienen of moet werken vanaf een mobiel netwerk dat geen inkomende verbindingen kan ontvangen, dan niet. Als het protocol IP-protocol 47 in plaats van een poort vereist, kan het netwerk weigeren het te leveren, ongeacht wat Windows ondersteunt.

Die drie antwoorden schrappen het grootste deel van de discussie in één keer. De rest is implementatiedetail.

Waar een router-eindpunt wint

Een tunnel die op de router eindigt, is de natuurlijke keuze voor permanente toegang. De router staat toch altijd aan, hij kan een tunnel tussen locaties naar een ander kantoor dragen, en clients hoeven niets te installeren als de router het protocol biedt dat zij gebruiken.

De beperking is firmware. Consumentenrouters ondersteunen vaak maar een deel van wat de specificatie toestaat, en een model dat VPN-ondersteuning adverteert, bevat misschien niet precies het protocol waarop je had gerekend. Controleer de functielijst van de geïnstalleerde firmware, niet die van de productfamilie.

Waar een OpenVPN-host wint

Een OpenVPN-server op een kleine, altijd aanstaande machine past bij gemengde clients, meerdere gebruikers met aparte inloggegevens en netwerken waar één uitgaande poort het verschil is tussen werken en geblokkeerd worden. Hij geeft per client een profiel uit, draait op alle grote platforms en gedraagt zich vanaf de clientkant als een gewone uitgaande toepassing.

Hij vraagt ook om een eigenaar. Iemand moet certificaten vernieuwen, hostupdates toepassen en het logboek lezen wanneer een client geen verbinding kan maken. Zonder die persoon verloedert een zelf gehost eindpunt stilletjes tot de dag dat het ertoe doet.

Controleer het pad voordat je toegang belooft

De meest voorkomende reden dat een Windows-listener faalt, is niet authenticatie. Het is het pad: PPTP vereist inkomende TCP 1723 en GRE, wat protocol 47 is en geen poort, en veel routers sturen alleen poorten door. Sommige toegangsnetwerken staan helemaal geen inkomende verbindingen toe. Dat ene feit sluit de ingebouwde listener op meer netwerken uit dan welke Windows-instelling dan ook.

Test het pad voordat je accounts configureert, zodat een fout één kandidaat heeft in plaats van drie:

Test-NetConnection -ComputerName 203.0.113.45 -Port 1723
Get-NetAdapterBinding | Where-Object ComponentID -like ms_pptp
ss -lunp | grep 1194

Een gesloten poort op de eerste regel is een doorstuur- of providerprobleem, geen Windows-probleem. De derde regel is de controle die je zou uitvoeren na de keuze voor OpenVPN, waar één luisterende UDP-poort de hele protocolvraag vervangt.

Welke optie je ook kiest, laat PPTP niet als langetermijnoplossing naar het internet wijzen; de authenticatie en versleuteling zijn verouderd. En als de echte behoefte één webapplicatie is, is een reverse proxy een kleiner antwoord dan welke VPN dan ook.