OpenVPN pada 443 masih disekat? Periksa apa yang diperiksa rangkaian

Tunnel bersambung dari talian rumah dan tersekat pada rangkaian hotel atau pejabat, dan memindahkan pelayan ke port 443 tidak mengubah apa-apa. Hasil itu cukup biasa sehingga mempunyai bentuk: port ialah bahagian yang mudah, dan baki keputusan milik apa sahaja yang duduk antara klien dan pelayan. Dua soalan menyelesaikan kebanyakan kes, dan tiada satu pun tentang sifer. Adakah rangkaian menerima jabat tangan TLS ke alamat itu, dan adakah klien mengekalkan laluan ke pembalutnya sendiri semasa tunnel hidup?

Jabat tangan mendedahkan lebih daripada nombor

Pendengar VPN asli pada TCP 443 bercakap protokolnya sendiri dari paket pertama. ClientHello mempunyai medan versi, nilai rawak dan senarai sambungan, dan peranti yang membaca beberapa ratus bait boleh melihat perbezaannya tanpa menyahsulit apa-apa. Nombor port murah untuk dipenuhi, dan bentuk protokol itulah yang benar-benar diperiksa oleh penapis. Peraturan biasanya juga ditulis mengikut protokol, jadi dasar yang memeriksa TLS tidak berkata apa-apa tentang UDP.

Proksi lutsinar yang menuntut sesi TLS yang sah memutuskan sambungan semasa penyediaan, selalunya selepas jabat tangan TCP selesai. Butiran itu penting kemudian, kerana ia bermakna log klien berhenti selepas soket diwujudkan.

Membalut aliran mencipta dua titik kegagalan

Pembalut TLS seperti stunnel memulihkan bentuk yang dijangka: klien bersambung ke pendengar tempatan, pembalut membuka sesi TLS sebenar ke pelayan pada 443, dan pembalut kedua pada pelayan memajukan bait yang dinyahsulit kepada daemon VPN. Sesi luar kini kelihatan seperti mana-mana sambungan HTTPS lain. Daemon VPN pada pelayan sepatutnya mendengar hanya pada loopback, kerana tiada apa-apa di luar pembalut perlu mencapainya.

Tiga perkara berasingan mesti sejajar untuk reka bentuk itu. Profil klien menunjuk ke pendengar tempatan, sijil pelayan sepadan dengan nama yang disahkan klien, dan pemajuan di sebelah pelayan menyasarkan port yang benar-benar digunakan daemon. Salah satu daripadanya silap dan sambungan mati sebelum lapisan VPN dicapai. Ketidakpadanan sijil kemudian muncul sebagai ralat pembalut dan bukan ralat VPN, dan sebab itulah kedua-dua log wajar dibaca bersebelahan.

Laluan ke pembalut itulah perangkapnya

Sebaik tunnel naik, laluan lalai menunjuk ke dalamnya, dan sesi TLS luar memerlukan laluan yang tidak masuk ke tunnel yang dibawanya. Klien VPN biasa melindungi alamat yang didailnya; klien berbalut mendail loopbacknya sendiri, jadi alamat destinasi pembalut tidak kelihatan kepada 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 sebenar anda isi sendiri, dan laluan mesti wujud sepanjang hayat sambungan, bukan hanya semasa bermula. Skrip pembalut kecil yang menambah laluan sebelum klien dan mengeluarkannya selepas itu lebih boleh dipercayai daripada arahan yang diingati.

Pada Android, persamaan pengecualian itu ialah tetapan bagi setiap aplikasi: kecualikan aplikasi pembalut daripada tunnel supaya trafiknya sendiri keluar melalui sambungan mudah alih. Tanpa pengecualian itu pembalut dilalukan ke dalam tunnel yang cuba dibinanya, dan gelung sambung semula kelihatan seperti masalah pelayan.

Baca masa sebelum mengubah apa-apa

Sesi yang mati selepas selang yang sama setiap kali ialah tandatangan dasar dan bukan kegagalan kriptografi, dan had aliran jangka panjang menghasilkan corak yang tepat itu. Sambungan yang ditetapkan semula sejurus selepas jabat tangan mencadangkan proksi yang tidak menyukai rantaian sijil.

Bandingkan pengeluar sijil tapak HTTPS biasa daripada kedua-dua rangkaian. Jika pengeluarnya berbeza pada rangkaian terhad, ada sesuatu yang menamatkan TLS di tengah, dan tiada pembalut akan bertahan daripada pemintasan itu tanpa perubahan. Perbandingan yang sama memberitahu anda sama ada sekatan menyasarkan nama pelayan anda atau setiap sesi TLS pada alamat itu.

Catat tingkah laku yang diperhatikan: berapa lama sesi bertahan, sama ada soket terbuka, sama ada pembalut merekod jabat tangan. Setiap satu menyempitkan ujian seterusnya.

Uji satu pemboleh ubah pada satu masa

Periksa UDP dahulu, kerana sesetengah rangkaian membuangnya sepenuhnya dan kegagalan UDP tidak berkata apa-apa tentang 443. Kemudian cuba TCP 443 tanpa pembalut, kemudian pembalut pada 443. Baca log klien pada setiap langkah dan berhenti sebaik sahaja tingkah laku berubah.

Tukar satu elemen setiap percubaan. Port baharu, pembalut baharu dan sifer baharu dalam larian yang sama membuatkan anda tidak boleh mengatakan mana antara tiga yang penting.