SSTP di balik proxy yang memeriksa TLS: di mana sesi putus

Peramban Anda memuat intranet perusahaan, sertifikat proxy dipercaya, tetapi klien SSTP tetap terputus di dekat akhir koneksi. Pola itu menunjukkan perbedaan antara permintaan web dan sesi dalam terowongan, bukan kata sandi yang salah. Telusuri koneksi dari TCP ke atas dan catat tahap pertama yang gagal. Tahapnya, bukan kode kesalahan, memberi tahu apakah proxy penyebabnya.

Mulai dari tempat klien berhenti

Klien melewati urutan tetap: koneksi TCP ke port 443, jabat tangan TLS, validasi sertifikat, pertukaran HTTP SSTP, negosiasi dan autentikasi PPP, lalu konfigurasi IP. Kegagalan pada tiap tahap meninggalkan jejak berbeda, dan mencampurnya membawa Anda ke halaman konfigurasi yang salah.

Kegagalan TCP adalah batas waktu atau reset sebelum satu byte TLS pun muncul. Kegagalan TLS adalah peringatan atau batas waktu jabat tangan. Kegagalan sertifikat menghasilkan peringatan tentang rantai atau nama. Kegagalan HTTP datang setelah jabat tangan berhasil, sering sebagai kode status atau penutupan segera. Kegagalan PPP datang setelah terowongan secara teknis terbentuk, karena itu tampak seperti masalah autentikasi.

Baca log klien untuk tahap terakhir yang berhasil, bukan baris kesalahan pertama. Baris kesalahan biasanya melaporkan akibatnya, sedangkan batas tahap menyebutkan komponen yang menolak.

Apa yang SSTP minta jaringan bawa

SSTP berjalan di atas TLS pada TCP 443 lalu mengirim permintaan HTTP bernama SSTP_DUPLEX_POST, yang didefinisikan dalam spesifikasi SSTP, ke jalur berbentuk /sra_{GUID}/. Permintaan itu menyatakan panjang konten yang praktis tak terbatas dan menjaga aliran tetap terbuka di kedua arah selama seluruh sesi. Bingkai PPP bergerak di dalam aliran itu.

Itulah sebabnya proxy yang menangani penjelajahan biasa tetap bisa gagal. GET atau POST dengan badan terbatas dapat disangga, diperiksa, dan diteruskan; aliran dupleks dengan badan yang tak pernah berakhir tidak bisa. Proxy yang menunggu badan selesai menunggu selamanya, dan klien akhirnya kehabisan waktu.

Penyaringan metode dan autentikasi menambahkan mode kegagalannya sendiri. Jika proxy meminta kredensial untuk permintaan itu, klien VPN mungkin tidak menjawab padahal peramban akan menjawab. Jika proxy menghapus atau menulis ulang metodenya, gateway menolak permintaan sebelum PPP dimulai.

Mengapa pemeriksaan mengubah identitas

Proxy yang memeriksa TLS mengakhiri koneksi TLS klien dan membuka koneksi terpisah ke gateway. Karena itu klien memvalidasi sertifikat proxy, bukan sertifikat gateway, dan gateway melihat proxy sebagai rekannya. Ketika organisasi membagikan akar miliknya sendiri, peramban dan klien VPN sama-sama dapat menerima rantai itu, sehingga jabat tangan berhasil dan masalahnya pindah ke tahap berikutnya.

Validasi yang berhasil bukan berarti proxy dapat membawa sesi. Proxy masih harus meneruskan POST dua arah tanpa batas tanpa penyanggaan, dan menjaga kedua koneksi tetap hidup berjam-jam. Banyak produk pemeriksaan dibangun untuk lalu lintas permintaan-jawaban dan menangani kasus ini dengan buruk atau tidak sama sekali.

Karena itu menambahkan akar tak dikenal atau mematikan verifikasi adalah perbaikan yang salah. Itu mengubah sertifikat mana yang diterima klien; itu tidak melakukan apa pun terhadap penanganan aliran yang sebenarnya memutus sesi.

Identifikasi penerbit sebelum mengubah pengaturan

Tanyakan kepada titik akhir sertifikat apa yang disajikannya dan siapa yang menandatanganinya. Perintah di bawah menunjukkan rantai dan penerbit tanpa memulai sesi VPN:

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

Jika penerbitnya CA publik, koneksi mungkin tidak dicegat untuk host ini dan kegagalannya ada di tempat lain. Jika penerbitnya CA milik organisasi sendiri, pemeriksaan aktif dan gateway dicapai melalui proxy. Bandingkan sidik jari dengan yang diharapkan tim jaringan sebelum menarik kesimpulan hanya dari namanya.

Uji peramban ke host yang sama hanya membuktikan bahwa proxy menerima GET. Itu tidak mengatakan apa pun tentang metode SSTP, URI permintaan, atau masa hidup badan, jadi jangan anggap halaman intranet yang berfungsi sebagai bukti bahwa jalur terowongan didukung.

Pilih jalur yang didukung

Tanyakan satu pertanyaan konkret kepada pemilik jaringan: apakah proxy mengizinkan POST dupleks tanpa penyangga ke gateway ini pada port 443? Jawaban ya mengarah ke pengecualian proxy atau jalur lewatan yang terdokumentasi untuk host VPN. Jawaban tidak berarti jalur yang diperiksa tidak dapat membawa SSTP, dan perbaikan yang didukung adalah jalur atau protokol lain, bukan penyesuaian klien.

Pilihannya biasanya mencakup jalan keluar yang tidak diperiksa untuk gateway VPN, desain terowongan terpisah yang hanya mengirim lalu lintas perusahaan melalui proxy, atau protokol alternatif yang didukung organisasi pada port lain. Masing-masing termasuk dalam desain jaringan, dan masing-masing harus diuji dengan perangkat dan profil yang sama agar perbandingannya mengisolasi jalur.

Dokumentasikan hasilnya: penerbit, tahap yang gagal, aturan proxy, dan jalur yang dipilih. Orang berikutnya yang melihat kemacetan 98 persen yang sama dapat memeriksa satu fakta alih-alih mengulang seluruh penelusuran.