SSTP proti OpenVPN: stejný port 443, jiný protokol

Obě možnosti mohou stát za TCP 443, a lidé proto předpokládají, že jde o zaměnitelné koncové body. Nejsou: SSTP server mluví PPP uvnitř HTTPS, zatímco server OpenVPN mluví vlastním protokolem přes TLS nebo hrubým UDP tokem. Nasměrování jednoho klienta na port druhého vytvoří spojení, které nikdy nedojde k přihlašovací výzvě. Volba se týká kterého klienta a jaký transport můžete podporovat, ne čísla.

Sdílený port nedělá sdílený protokol

TLS handshake může doběhnout a přesto nikam nevést, protože klient a server se pak neshodnou, co říct dál. V zachycení paketů vidíte čistý handshake, po kterém následují data aplikace, která protistrana odmítá nebo ignoruje. Tento vzor je podpisem neshody protokolů, nikoli blokace firewallem.

Ani přejmenovaný profil ani jiná položka menu nepřevádí jedno v druhé. SSTP spojení se vytváří v nastavení VPN ve Windows s adresou serveru a ověřovacími údaji operátora, zatímco OpenVPN spojení potřebuje klienta a odpovídající konfigurační soubor. Specifikace SSTP od Microsoftu popisuje první případ a nepopisuje OpenVPN handshake.

Port 443 je pohodlí politiky. Projde sítěmi, které povolují málo jiného, a to je skutečná výhoda, ale neříká nic o tom, který protokol za ním běží.

SSTP tuneluje PPP uvnitř HTTPS

Název popisuje konstrukci: rámce PPP nesené uvnitř relace HTTPS, což znamená TLS pod nimi a certifikát, který klient může zkontrolovat. Windows to zahrnuje jako nativní typ VPN, takže spravovaný notebook se často připojí bez dalšího softwaru kromě profilu, který dodá operátor.

Jiné platformy jsou jiný příběh. Klient pro Linux nebo macOS potřebuje udržovanou implementaci a ty se liší v tom, co podporují a jak hlásí chyby. Zkontrolujte klienta, kterého skutečně hodláte použít, místo abyste předpokládali, že se vestavěná schopnost Windows přenese, a potvrďte, že název serveru v profilu odpovídá certifikátu, který server předkládá.

SSTP je obvykle jen TCP. Tento jediný transport ovlivňuje, jak se chová na lince se ztrátami, protože opětovné přenosy probíhají uvnitř tunelu i pod ním.

OpenVPN přináší vlastního klienta a volbu transportu

OpenVPN dodává vlastního klienta a profil, což vám dá diagnostiku, kterou nativní dialog Windows neukáže. Server může naslouchat na UDP nebo TCP a konfigurace operátora rozhoduje, který z nich váš klient musí použít. Profil namířený na špatný transport selže ještě před ověřením.

Ověřování je stejně řízeno konfigurací. Nasazení může vyžadovat jen certifikáty, certifikáty plus uživatelské jméno a heslo, nebo druhý faktor navrch, a klient musí přesně odpovídat tomuto uspořádání. To, že spojení dosáhne fáze TLS, neříká, jaké přihlašovací údaje si vyžádá dál.

UDP je obvyklé výchozí nastavení, protože se vyhýbá vnořování spolehlivého toku do jiného spolehlivého toku. Režim TCP existuje pro sítě, které blokují UDP, a funguje, ale velké ztráty ho mohou udělat horším než UDP cesta, kterou nahradil. Volte TCP, když musíte, ne proto, že zní spolehlivěji.

Vybírejte podle klienta, transportu a podpory

Tři otázky rozhodnou většinu těchto voleb. Potřebuje každé klientské zařízení spojení, které funguje bez dalšího softwaru? Dovoluje síť, na kterou spoléháte, UDP, nebo je TCP 443 jediný východ? A kdo podporuje klienta, jeho aktualizace a jeho obnovu, když profil vyprší?

Když obě porovnáváte, testujte na stejném zařízení a ve stejné přístupové síti. Pokud jsou koncový bod SSTP a koncový bod OpenVPN různé servery nebo různá místa, váš výsledek zahrnuje tyto trasy a stroje, místo aby izoloval protokol. To je nejčastější způsob, jak taková srovnání dají sebevědomou, ale špatnou odpověď.

Potom si potvrďte, které z nich jste skutečně navázali, než začnete cokoli dalšího ladit:

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

Ať tak či onak, skončete testem prostředku a DNS, které potřebujete, místo abyste hlásili úspěch ve stavu tunelu. Oba protokoly lze nakonfigurovat tak, aby přenášely jen vybraný soukromý provoz, a připojený tunel bez fungujícího překladu jmen vypadá jako rozbitá VPN, když je ve skutečnosti návrhem split-tunnelu nebo DNS.

Ve spravované flotile distribuce profilů a podpora aktualizací obvykle rozhodnou otázku dávno před jakýmkoli měřením transportu.