SSTP sa likod ng proxy na nagsusuri ng TLS: saan napuputol ang sesyon

Naglo-load ang browser mo ng corporate intranet, pinagkakatiwalaan ang sertipiko ng proxy, at nabubuwal pa rin ang kliyenteng SSTP malapit sa dulo ng koneksyon. Itinuturo ng pattern na ito ang pagkakaiba ng web request at ng sesyong nasa tunnel, hindi ang maling password. Daanan ang koneksyon mula TCP pataas at itala ang unang yugtong nabigo. Ang yugto, hindi ang error code, ang nagsasabi kung ang proxy ang dahilan.

Magsimula kung saan humihinto ang kliyente

Dumadaan ang kliyente sa isang takdang pagkakasunod-sunod: TCP na koneksyon sa port 443, TLS handshake, pagpapatunay ng sertipiko, ang HTTP exchange ng SSTP, PPP negotiation at authentication, pagkatapos ang IP configuration. Nag-iiwan ng ibang bakas ang pagkabigo sa bawat yugto, at ang paghahalo sa mga ito ay magdadala sa iyo sa maling pahina ng configuration.

Ang kabiguan sa TCP ay timeout o reset bago pa man lumitaw ang kahit isang byte ng TLS. Ang kabiguan sa TLS ay alerto o timeout ng handshake. Ang kabiguan sa sertipiko ay naglalabas ng babala tungkol sa kadena o pangalan. Ang kabiguan sa HTTP ay dumarating pagkatapos ng matagumpay na handshake, madalas bilang status code o agad na pagsasara. Ang kabiguan sa PPP ay dumarating pagkatapos na teknikal na maitayo ang tunnel, kaya mukha itong problema sa authentication.

Basahin ang log ng kliyente para sa huling matagumpay na yugto, hindi ang unang linya ng error. Karaniwang iniuulat ng linya ng error ang bunga, samantalang pinangalanan ng hangganan ng yugto ang bahaging tumanggi.

Ano ang hinihiling ng SSTP na dalhin ng network

Tumakbo ang SSTP sa ibabaw ng TLS sa TCP 443 at pagkatapos ay nagpapadala ng HTTP request na tinatawag na SSTP_DUPLEX_POST, na tinukoy sa espesipikasyon ng SSTP, patungo sa landas na may anyong /sra_{GUID}/. Idinideklara ng request ang halos walang hanggang haba ng nilalaman at pinananatiling bukas ang stream sa dalawang direksyon sa buong buhay ng sesyon. Naglalakbay ang mga PPP frame sa loob ng stream na iyon.

Kaya ang proxy na humahawak ng ordinaryong pagba-browse ay maaari pa ring mabigo. Ang GET o POST na may hangganang katawan ay maaaring i-buffer, suriin at ipasa; ang duplex stream na may katawang hindi natatapos ay hindi. Ang proxy na naghihintay matapos ang katawan ay naghihintay magpakailanman, at sa huli ay nagti-timeout ang kliyente.

Nagdaragdag ng sariling failure mode ang pag-filter ng method at authentication. Kung humihingi ng kredensyal ang proxy para sa request, maaaring hindi sumagot ang VPN client kahit sasagot ang browser. Kung aalisin o isusulat muli nito ang method, tinatanggihan ng gateway ang request bago pa magsimula ang PPP.

Bakit binabago ng pagsusuri ang pagkakakilanlan

Ang proxy na nagsusuri ng TLS ay tinatapos ang TLS connection ng kliyente at nagbubukas ng hiwalay na koneksyon patungo sa gateway. Kaya pinapatunayan ng kliyente ang sertipiko ng proxy, hindi ang sa gateway, at nakikita ng gateway ang proxy bilang kapareha nito. Kapag ipinamahagi ng organisasyon ang sariling root nito, maaaring tanggapin ng browser at ng VPN client ang kadenang iyon, kaya nagtatagumpay ang handshake at lumilipat ang problema sa susunod na yugto.

Ang matagumpay na pagpapatunay ay hindi nangangahulugang kaya nang dalhin ng proxy ang sesyon. Kailangan pa rin nitong ipasa ang walang hanggang bidirectional na POST nang walang buffering, at panatilihing buhay ang dalawang koneksyon nang maraming oras. Maraming produkto ng pagsusuri ay ginawa para sa trapikong request-response at hindi maganda o hindi talaga hinahawakan ang kasong ito.

Kaya ang pagdaragdag ng hindi kilalang root o pagpatay sa verification ay maling pagkukumpuni. Binabago nito kung aling sertipiko ang tinatanggap ng kliyente; wala itong ginagawa sa paghawak ng stream na talagang sinira ang sesyon.

Tukuyin ang issuer bago baguhin ang mga setting

Tanungin ang endpoint kung aling sertipiko ang ipinapakita nito at sino ang pumirma. Ipinapakita ng mga command sa ibaba ang kadena at ang issuer nang hindi nagsisimula ng VPN session:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Kung pampublikong CA ang issuer, malamang hindi nahaharang ang koneksyon para sa host na ito at nasa ibang lugar ang kabiguan. Kung sariling CA ng organisasyon ang issuer, aktibo ang pagsusuri at naaabot ang gateway sa pamamagitan ng proxy. Ihambing ang fingerprint sa inaasahan ng network team bago magpasya batay sa pangalan lamang.

Ang pagsubok ng browser sa parehong host ay nagpapatunay lamang na tinatanggap ng proxy ang GET. Wala itong sinasabi tungkol sa method ng SSTP, sa URI ng request o sa buhay ng katawan, kaya huwag ituring na patunay na sinusuportahan ang daan ng tunnel ang isang gumaganang pahina ng intranet.

Piliin ang sinusuportahang landas

Tanungin ang may-ari ng network ng isang konkretong tanong: pinapayagan ba ng proxy ang duplex na POST na walang buffer patungo sa gateway na ito sa port 443? Ang oo ay humahantong sa exception sa proxy o sa dokumentadong pag-iwas para sa VPN host. Ang hindi ay nangangahulugang hindi kayang dalhin ng sinuring landas ang SSTP, at ang sinusuportahang pagtatama ay ibang landas o protocol, hindi pagsasaayos ng kliyente.

Karaniwang kasama sa mga opsyon ang hindi sinuring labasan para sa VPN gateway, disenyong split tunnel na nagpapadala lamang ng corporate traffic sa proxy, o alternatibong protocol na sinusuportahan ng organisasyon sa ibang port. Bahagi ng disenyo ng network ang bawat isa, at dapat subukan ang bawat isa sa parehong device at profile upang ihiwalay ng paghahambing ang landas.

Idokumento ang resulta: issuer, yugtong nabigo, patakaran ng proxy at piniling landas. Ang susunod na taong makakita ng parehong pagtigil sa 98 porsiyento ay makakapagpatunay ng isang katotohanan sa halip na ulitin ang buong paglalakbay.