SSTP mot OpenVPN: samme port 443, annen protokoll

Begge alternativene kan ligge bak TCP 443, så folk antar at de er utskiftbare endepunkter. Det er de ikke: SSTP server snakker PPP inne i HTTPS, mens en OpenVPN-server snakker sin egen protokoll over TLS eller en rå UDP-strøm. Å peke én klient mot den andres port gir en forbindelse som aldri når en innloggingsforespørsel. Valget handler om hvilken klient og transport du kan støtte, ikke om nummeret.

En delt port gir ikke en delt protokoll

TLS-håndtrykken kan fullføres og likevel ikke føre noe sted, fordi klienten og serveren etterpå er uenige om hva som skal sies neste gang. I en pakkeopptak ser du et rent håndtrykk etterfulgt av applikasjonsdata som motparten avviser eller ignorerer. Det mønsteret er signaturen på en protokoll-uoverensstemmelse og ikke en blokkering fra brannmuren.

Verken en omdøpt profil eller et annet menyelement gjør den ene om til den andre. En SSTP-forbindelse opprettes fra Windows' VPN-innstillinger med en serveradresse og operatørens påloggingsdetaljer, mens en OpenVPN-forbindelse trenger klienten og den tilhørende konfigurasjonsfilen. Microsofts SSTP-spesifikasjon beskriver det første og beskriver ikke et OpenVPN-håndtrykk.

Port 443 er en bekvemmelighet i policyen. Den slipper gjennom nettverk som tillater lite annet, og det er en reell fordel, men den sier ingenting om hvilken protokoll som kjører bak den.

SSTP tunnelerer PPP inne i HTTPS

Navnet beskriver konstruksjonen: PPP-rammer som bæres inne i en HTTPS-økt, altså TLS under og et sertifikat klienten kan kontrollere. Windows inkluderer dette som en innebygd VPN-type, så en administrert bærbar maskin kan ofte koble til uten ekstra programvare utover profilen operatøren leverer.

Andre plattformer er en annen historie. En Linux- eller macOS-klient trenger en vedlikeholdt implementasjon, og de varierer i hva de støtter og hvordan de rapporterer feil. Kontroller klienten du faktisk har tenkt å bruke i stedet for å anta at Windows' innebygde evne overføres, og bekreft at servernavnet i profilen samsvarer med sertifikatet serveren presenterer.

SSTP er vanligvis bare TCP. Den ene transporten påvirker hvordan den oppfører seg på en lenke med tap, fordi videresending skjer både inne i tunnelen og under den.

OpenVPN har sin egen klient og et transportvalg

OpenVPN leverer sin egen klient og profil, noe som gir deg diagnostikk som en innebygd Windows-dialog ikke viser. Serveren kan lytte på UDP eller TCP, og operatørens konfigurasjon avgjør hvilken klienten din må bruke. En profil rettet mot feil transport feiler før autentiseringen.

Autentisering styres like mye av konfigurasjonen. En utrulling kan kreve bare sertifikater, sertifikater pluss et brukernavn og passord, eller en annen faktor på toppen, og klienten må samsvare nøyaktig med den ordningen. At en forbindelse når TLS-trinnet, sier ikke hvilke påloggingsdetaljer den vil be om neste gang.

UDP er standardvalget fordi det unngår å pakke en pålitelig strøm inn i en annen pålitelig strøm. TCP-modus finnes for nettverk som blokkerer UDP, og den virker, men store tap kan få den til å føles verre enn UDP-veien den erstattet. Velg TCP når du må, ikke fordi det høres mer pålitelig ut.

Velg etter klient, transport og støtte

Tre spørsmål avgjør de fleste av disse beslutningene. Trenger hver klientenhet en forbindelse som virker uten ekstra programvare? Tillater nettverket du er avhengig av UDP, eller er TCP 443 den eneste utgangen? Og hvem støtter klienten, oppdateringene og gjenopprettingen når en profil utløper?

Når du sammenligner de to, test på samme enhet og samme aksessnettverk. Hvis SSTP-endepunktet og OpenVPN-endepunktet er forskjellige servere eller forskjellige steder, inneholder resultatet ditt disse rutene og maskinene i stedet for å isolere protokollen. Det er den vanligste måten slike sammenligninger gir et selvsikkert men feil svar.

Bekreft deretter hvilken du faktisk etablerte før du feilsøker noe annet:

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

Uansett, avslutt med å teste ressursen og DNS-en du trenger i stedet for å erklære suksess ved tunnelens tilstand. Begge protokollene kan konfigureres til å bære bare utvalgt privat trafikk, og en tilkoblet tunnel uten fungerende navneoppslag ser ut som en ødelagt VPN når det egentlig er et split-tunnel- eller DNS-design.

I en administrert flåte avgjør profildistribusjon og oppdateringsstøtte spørsmålet vanligvis lenge før noen transportmåling.