OpenVPN di 443 masih diblokir? Periksa apa yang diperiksa jaringan

Tunnel tersambung dari saluran rumah dan macet di jaringan hotel atau kantor, dan memindahkan server ke port 443 tidak mengubah apa pun. Hasil itu cukup umum sehingga punya bentuk: port adalah bagian yang mudah, dan sisa keputusannya milik apa pun yang duduk di antara klien dan server. Dua pertanyaan menyelesaikan sebagian besar kasus, dan tidak satu pun soal cipher. Apakah jaringan menerima jabat tangan TLS ke alamat itu, dan apakah klien mempertahankan rute ke pembungkusnya sendiri selama tunnel menyala?

Jabat tangan membocorkan lebih dari nomornya

Pendengar VPN asli di TCP 443 berbicara protokolnya sendiri sejak paket pertama. ClientHello punya bidang versi, nilai acak, dan daftar ekstensi, dan perangkat yang membaca beberapa ratus byte bisa melihat perbedaannya tanpa mendekripsi apa pun. Nomor port murah untuk dipenuhi, dan bentuk protokol itulah yang sebenarnya diperiksa filter. Aturan biasanya juga ditulis per protokol, jadi kebijakan yang memeriksa TLS tidak mengatakan apa pun tentang UDP.

Proksi transparan yang menuntut sesi TLS sah memutus koneksi saat penyiapan, sering setelah jabat tangan TCP selesai. Detail itu penting nanti, karena artinya log klien berhenti setelah soket terbentuk.

Membungkus aliran menciptakan dua titik gagal

Pembungkus TLS seperti stunnel memulihkan bentuk yang diharapkan: klien tersambung ke pendengar lokal, pembungkus membuka sesi TLS sungguhan ke server di 443, dan pembungkus kedua di server meneruskan byte yang didekripsi ke daemon VPN. Sesi luar sekarang tampak seperti koneksi HTTPS lainnya. Daemon VPN di server sebaiknya hanya mendengarkan di loopback, karena tidak ada apa pun di luar pembungkus yang perlu mencapainya.

Tiga hal terpisah harus sejajar untuk rancangan itu. Profil klien menunjuk ke pendengar lokal, sertifikat server cocok dengan nama yang diverifikasi klien, dan penerusan di sisi server menyasar port yang benar-benar dipakai daemon. Salah satu saja keliru, koneksi mati sebelum lapisan VPN tercapai. Ketidakcocokan sertifikat lalu muncul sebagai kesalahan pembungkus dan bukan kesalahan VPN, dan karena itu kedua log layak dibaca berdampingan.

Rute ke pembungkus adalah jebakannya

Begitu tunnel naik, rute bawaan menunjuk ke dalamnya, dan sesi TLS luar butuh jalur yang tidak masuk ke tunnel yang dibawanya. Klien VPN biasa melindungi alamat yang dihubunginya; klien terbungkus menghubungi loopback-nya sendiri, jadi alamat tujuan pembungkus tidak terlihat oleh perlindungan itu.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Alamat persisnya Anda isi sendiri, dan rute harus ada sepanjang umur koneksi, bukan hanya saat mulai. Skrip pembungkus kecil yang menambahkan rute sebelum klien dan menghapusnya sesudahnya lebih andal daripada perintah yang diingat.

Di Android, padanan pengecualian itu adalah pengaturan per aplikasi: kecualikan aplikasi pembungkus dari tunnel agar lalu lintasnya sendiri keluar lewat koneksi seluler. Tanpa pengecualian itu, pembungkus dirutekan ke dalam tunnel yang hendak dibangunnya, dan lingkar sambung ulang tampak seperti masalah server.

Baca waktunya sebelum mengubah apa pun

Sesi yang mati setelah selang yang sama setiap kali adalah tanda tangan kebijakan dan bukan kegagalan kriptografis, dan batas aliran berumur panjang menghasilkan pola persis seperti itu. Koneksi yang direset tepat setelah jabat tangan menyarankan proksi yang tidak menyukai rantai sertifikat.

Bandingkan penerbit sertifikat situs HTTPS biasa dari kedua jaringan. Jika penerbitnya berbeda di jaringan terbatas, ada sesuatu yang mengakhiri TLS di tengah, dan tidak ada pembungkus yang bertahan dari penyadapan itu tanpa perubahan. Perbandingan yang sama memberi tahu Anda apakah blokir menyasar nama server Anda atau setiap sesi TLS di alamat itu.

Catat perilaku yang teramati: berapa lama sesi bertahan, apakah soket terbuka, apakah pembungkus mencatat jabat tangan. Tiap-tiap itu mempersempit uji berikutnya.

Uji satu variabel setiap kali

Periksa UDP lebih dulu, karena sebagian jaringan membuangnya sepenuhnya dan kegagalan UDP tidak mengatakan apa pun tentang 443. Lalu coba TCP 443 tanpa pembungkus, kemudian pembungkus di 443. Baca log klien di setiap langkah dan berhenti begitu perilakunya berubah.

Ubah satu elemen per percobaan. Port baru, pembungkus baru, dan cipher baru dalam satu jalan membuat Anda tidak bisa mengatakan mana dari ketiganya yang penting.