SSTP versus OpenVPN: dezelfde poort 443, ander protocol

Beide opties kunnen achter TCP 443 zitten, dus mensen nemen aan dat het uitwisselbare eindpunten zijn. Dat zijn ze niet: SSTP server spreekt PPP binnen HTTPS, terwijl een OpenVPN-server zijn eigen protocol spreekt over TLS of via een ruwe UDP-stroom. Een client op de poort van de ander richten levert een verbinding op die nooit bij een inlogprompt komt. De keuze gaat over welke client en welk transport je kunt ondersteunen, niet over het nummer.

Een gedeelde poort maakt nog geen gedeeld protocol

De TLS-handshake kan voltooien en toch nergens heen leiden, omdat de client en de server het daarna oneens zijn over wat er vervolgens gezegd moet worden. In een pakketopname zie je een schone handshake gevolgd door applicatiegegevens die de tegenpartij weigert of negeert. Dat patroon is de signatuur van een protocolverschil en niet van een blokkade door de firewall.

Noch een hernoemd profiel noch een ander menu-item maakt het ene het andere. Een SSTP-verbinding wordt aangemaakt in de Windows-VPN-instellingen met een serveradres en de authenticatiegegevens van de operator, terwijl een OpenVPN-verbinding de client en het bijbehorende configuratiebestand nodig heeft. Microsofts SSTP-specificatie beschrijft het eerste en beschrijft geen OpenVPN-handshake.

Poort 443 is een beleidsgemak. Hij komt door netwerken die weinig anders toestaan, en dat is een echt voordeel, maar hij zegt niets over welk protocol erachter draait.

SSTP tunnelt PPP binnen HTTPS

De naam beschrijft de constructie: PPP-frames die binnen een HTTPS-sessie worden vervoerd, dus TLS eronder en een certificaat dat de client kan controleren. Windows bevat dit als native VPN-type, zodat een beheerde laptop vaak kan verbinden zonder extra software naast het profiel dat de operator levert.

Andere platforms zijn een ander verhaal. Een Linux- of macOS-client vereist een onderhouden implementatie, en die verschillen in wat ze ondersteunen en hoe ze fouten melden. Controleer de client die je echt wilt gebruiken in plaats van aan te nemen dat de ingebouwde Windows-mogelijkheid overgaat, en bevestig dat de servernaam in het profiel overeenkomt met het certificaat dat de server presenteert.

SSTP is meestal alleen TCP. Dat ene transport beïnvloedt hoe het zich gedraagt op een verbinding met verlies, omdat herverzending zowel in de tunnel als eronder plaatsvindt.

OpenVPN brengt zijn eigen client en een transportkeuze mee

OpenVPN levert zijn eigen client en profiel, wat je diagnostiek geeft die een native Windows-dialoog niet toont. De server kan luisteren op UDP of TCP, en de configuratie van de operator bepaalt welke jouw client moet gebruiken. Een profiel dat op het verkeerde transport is gericht, faalt vóór de authenticatie.

Authenticatie is evenzeer configuratiegestuurd. Een uitrol kan alleen certificaten vereisen, certificaten plus een gebruikersnaam en wachtwoord, of een tweede factor daarbovenop, en de client moet precies bij die opzet passen. Dat een verbinding de TLS-fase bereikt, zegt niet welke inloggegevens hij daarna vraagt.

UDP is de gebruikelijke standaard omdat het voorkomt dat een betrouwbare stroom in een andere betrouwbare stroom wordt genest. De TCP-modus bestaat voor netwerken die UDP blokkeren, en hij werkt, maar zwaar verlies kan hem slechter laten voelen dan het UDP-pad dat hij heeft vervangen. Kies TCP als het moet, niet omdat het betrouwbaarder klinkt.

Kies op client, transport en ondersteuning

Drie vragen beslechten de meeste van deze beslissingen. Heeft elk clientapparaat een verbinding nodig die zonder extra software werkt? Staat het netwerk waarvan je afhankelijk bent UDP toe, of is TCP 443 de enige uitgang? En wie ondersteunt de client, zijn updates en zijn herstel wanneer een profiel verloopt?

Test bij het vergelijken van de twee op hetzelfde apparaat en hetzelfde toegangsnetwerk. Als het SSTP-eindpunt en het OpenVPN-eindpunt verschillende servers of verschillende locaties zijn, bevat je resultaat die routes en machines in plaats van het protocol te isoleren. Dat is de meest voorkomende manier waarop zulke vergelijkingen een zelfverzekerd maar verkeerd antwoord geven.

Bevestig daarna welke je werkelijk hebt opgezet voordat je iets anders debugt:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

Hoe dan ook, sluit af met het testen van de bron en de DNS die je nodig hebt in plaats van succes bij de tunnelstatus te verklaren. Beide protocollen kunnen worden geconfigureerd om alleen geselecteerd privéverkeer te dragen, en een verbonden tunnel zonder werkende naamresolutie ziet eruit als een kapotte VPN terwijl het in werkelijkheid een split-tunnel- of DNS-ontwerp is.

In een beheerde vloot beslissen profieldistributie en updateondersteuning de vraag meestal lang voordat enige transportmeting dat doet.