SSTP di sebalik proksi yang memeriksa TLS: di mana sesi terputus

Pelayar anda memuatkan intranet korporat, sijil proksi dipercayai, namun klien SSTP masih terputus hampir di hujung sambungan. Corak itu menunjukkan perbezaan antara permintaan web dan sesi dalam terowong, bukan kata laluan yang salah. Telusuri sambungan dari TCP ke atas dan catat peringkat pertama yang gagal. Peringkat itu, bukan kod ralat, memberitahu sama ada proksi punca masalah.

Mulakan di tempat klien berhenti

Klien melalui urutan tetap: sambungan TCP ke port 443, jabat tangan TLS, pengesahan sijil, pertukaran HTTP SSTP, rundingan dan pengesahan PPP, kemudian konfigurasi IP. Kegagalan pada setiap peringkat meninggalkan jejak berbeza, dan mencampurkannya membawa anda ke halaman konfigurasi yang salah.

Kegagalan TCP ialah tamat masa atau set semula sebelum sebarang bait TLS muncul. Kegagalan TLS ialah amaran atau tamat masa jabat tangan. Kegagalan sijil menghasilkan amaran tentang rantaian atau nama. Kegagalan HTTP datang selepas jabat tangan berjaya, selalunya sebagai kod status atau penutupan segera. Kegagalan PPP datang selepas terowong dibina secara teknikal, sebab itu ia kelihatan seperti masalah pengesahan.

Baca log klien untuk peringkat terakhir yang berjaya, bukan baris ralat pertama. Baris ralat biasanya melaporkan akibatnya, manakala sempadan peringkat menamakan komponen yang menolak.

Apa yang SSTP minta rangkaian bawa

SSTP berjalan di atas TLS pada TCP 443 dan kemudian menghantar permintaan HTTP bernama SSTP_DUPLEX_POST, yang ditakrifkan dalam spesifikasi SSTP, ke laluan berbentuk /sra_{GUID}/. Permintaan itu mengisytiharkan panjang kandungan yang hampir tidak terhad dan mengekalkan aliran terbuka dalam kedua-dua arah sepanjang hayat sesi. Bingkai PPP bergerak di dalam aliran itu.

Sebab itu proksi yang mengendalikan pelayaran biasa masih boleh gagal. GET atau POST dengan badan terhad boleh dibuffer, diperiksa dan dihantar; aliran dupleks dengan badan yang tidak pernah berakhir tidak boleh. Proksi yang menunggu badan selesai menunggu selamanya, dan klien akhirnya tamat masa.

Penapisan kaedah dan pengesahan menambah mod kegagalan mereka sendiri. Jika proksi meminta kelayakan untuk permintaan itu, klien VPN mungkin tidak menjawab walaupun pelayar akan menjawab. Jika ia membuang atau menulis semula kaedah itu, gateway menolak permintaan sebelum PPP bermula.

Mengapa pemeriksaan mengubah identiti

Proksi yang memeriksa TLS menamatkan sambungan TLS klien dan membuka sambungan berasingan ke gateway. Oleh itu klien mengesahkan sijil proksi, bukan sijil gateway, dan gateway melihat proksi sebagai rakan sejawatnya. Apabila organisasi mengedarkan akarnya sendiri, pelayar dan klien VPN kedua-duanya boleh menerima rantaian itu, jadi jabat tangan berjaya dan masalah berpindah ke peringkat seterusnya.

Pengesahan yang berjaya tidak bermakna proksi boleh membawa sesi. Ia masih perlu menyampaikan POST dua hala tanpa had tanpa buffering, dan mengekalkan kedua-dua sambungan hidup berjam-jam. Banyak produk pemeriksaan dibina untuk trafik permintaan-balasan dan mengendalikan kes ini dengan buruk atau tidak langsung.

Sebab itu menambah akar tidak dikenali atau mematikan pengesahan ialah pembaikan yang salah. Ia mengubah sijil mana yang diterima klien; ia tidak melakukan apa-apa tentang pengendalian aliran yang sebenarnya memutuskan sesi.

Kenal pasti pengeluar sebelum menukar tetapan

Tanya titik akhir sijil apa yang dipersembahkannya dan siapa yang menandatanganinya. Perintah di bawah menunjukkan rantaian dan pengeluar tanpa memulakan sesi VPN:

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

Jika pengeluar ialah CA awam, sambungan mungkin tidak dipintas untuk hos ini dan kegagalan ada di tempat lain. Jika pengeluar ialah CA organisasi sendiri, pemeriksaan aktif dan gateway dicapai melalui proksi. Bandingkan cap jari dengan yang dijangka oleh pasukan rangkaian sebelum membuat kesimpulan hanya daripada nama.

Ujian pelayar ke hos yang sama hanya membuktikan bahawa proksi menerima GET. Ia tidak menyatakan apa-apa tentang kaedah SSTP, URI permintaan atau hayat badan, jadi jangan anggap halaman intranet yang berfungsi sebagai bukti bahawa laluan terowong disokong.

Pilih laluan yang disokong

Tanya pemilik rangkaian satu soalan konkrit: adakah proksi membenarkan POST dupleks tanpa buffering ke gateway ini pada port 443? Ya membawa kepada pengecualian proksi atau lencongan berdokumen untuk hos VPN. Tidak bermakna laluan yang diperiksa tidak boleh membawa SSTP, dan pembaikan yang disokong ialah laluan atau protokol lain, bukan pelarasan klien.

Pilihan biasanya termasuk keluaran yang tidak diperiksa untuk gateway VPN, reka bentuk terowong berpecah yang hanya menghantar trafik korporat melalui proksi, atau protokol alternatif yang disokong organisasi pada port lain. Setiap satu tergolong dalam reka bentuk rangkaian, dan setiap satu patut diuji dengan peranti dan profil yang sama supaya perbandingan mengasingkan laluan.

Dokumenkan hasilnya: pengeluar, peringkat gagal, peraturan proksi dan laluan dipilih. Orang seterusnya yang melihat genangan 98 peratus yang sama boleh menyemak satu fakta dan bukannya mengulangi seluruh penelusuran.