VPN diblokir di jaringan hanya web? Kerjakan lapisannya

Jaringan kampus atau hotel tempat peramban berfungsi dan setiap terowongan mati bukan satu masalah, melainkan empat yang bertumpuk. Jalur itu mungkin hanya mengizinkan TCP 443, menuntut proksi terautentikasi, memeriksa jabat tangan, atau sekadar melarang akses jarak jauh lewat kebijakan. Menanganinya berurutan mencegah Anda membeli klien baru untuk memperbaiki aturan jaringan. Panduan di bawah memakan waktu sekitar sepuluh menit dan berakhir dengan jawaban tertulis tentang lapisan mana yang menolak Anda.

Buktikan lapisan mana yang menolak koneksi

Jangan mulai dari klien VPN. Mulailah dengan permintaan HTTPS biasa ke host yang sama dan baca fase waktunya, karena fase yang gagal memberi tahu perangkat mana yang bertanggung jawab:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Tanpa respons dan tanpa waktu connect berarti TCP tidak pernah selesai, jadi firewall, persyaratan proksi, atau tujuan yang salah sedang bermain. Waktu connect tanpa waktu tls berarti sesuatu di tengah menerima koneksi lalu menghentikan jabat tangan, dan begitulah tampilan proksi pemeriksa dari sisi klien.

Sekarang periksa sertifikat yang benar-benar Anda terima. Ini cara tercepat mengetahui apakah Anda berbicara dengan server atau dengan kotak perantara yang menandatangani ulang sesi:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Baca baris penerbit. CA Anda sendiri berarti Anda mencapai layanan; penerbit korporat atau perangkat berarti filter mengakhiri koneksi dan memutuskan apa yang terjadi berikutnya. Catat kedua keluaran dengan cap waktu, karena uji yang sama satu jam kemudian di jaringan tamu bisa memberi jawaban berbeda.

Klien yang sadar proksi mengubah paket pertama, bukan kebijakan

Jika jaringan menuntut CONNECT melalui proksi terautentikasi, klien VPN harus diberi tahu, atau ia akan mencoba membuka soket ke alamat yang tidak dapat dirutekannya. Uji proksi terpisah dari klien, agar kegagalan punya satu penjelasan:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Perintah pertama membuktikan proksi akan membawa tujuan. Yang kedua meminta klien memakai TCP pada 443, satu-satunya transport yang akan diteruskan sebagian besar jalur hanya web. Jika perintah pertama berhasil dan yang kedua masih gagal, proksi bukan penghalang.

Sebagian klien membaca proksi sistem operasi alih-alih penimpaan, dan sebagian tidak membaca keduanya. Periksa dokumentasi aplikasi sebelum menganggap pengaturan seluruh sistem berlaku. Klien yang menyelesaikan titik akhir lewat resolver yang tidak dilayani proksi juga akan gagal di sini, dan itulah sebabnya perubahan DNS bisa tampak seperti perbaikan padahal hanya jalan memutar.

Perhatikan juga pola pengarahan. Jaringan yang difilter dapat menjawab nama host deteksi vendor dengan sesuatu miliknya sendiri, yang mengubah profil proksi mana yang dipilih klien. Jangan membangun proses di sekitar keanehan itu. Itu berbeda per situs, berubah tanpa pemberitahuan, dan bukan sesuatu yang dapat Anda dukung untuk orang lain.

Port 443 dapat dijangkau, bukan diizinkan

Membungkus terowongan dalam TLS pada 443 menyelesaikan keterjangkauan dan tidak lebih. Filter yang memeriksa port akan meloloskannya; filter yang mengambil sidik jari jabat tangan tidak, dan sapaan klien terenkripsi hanya menyembunyikan nama server bila kedua ujung mendukungnya. Jalankan uji dan cari tahu jenis filter apa yang ada di depan Anda alih-alih berharap.

Ada juga biaya kinerja yang orang temukan belakangan. Transport andal di dalam transport andal memperkuat kehilangan, karena tumpukan dalam mengirim ulang segmen yang sudah dikirim ulang tumpukan luar. Pada tautan bersih tidak ada yang menyadari. Pada jaringan nirkabel kampus yang padat terowongan menjadi tidak terpakai tepat saat Anda membutuhkannya, dan grafiknya tampak seperti kehilangan paket padahal tidak ada yang sengaja dibuang.

UDP biasanya korban pertama, dan itu layak dipastikan alih-alih disimpulkan. Jika WireGuard atau OpenVPN bawaan tidak pernah menyelesaikan jabat tangan sementara TCP 443 berfungsi, jaringan menjatuhkan UDP, dan tidak ada regenerasi kunci yang akan mengubahnya:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Cap waktu jabat tangan kosong di samping peer yang kemarin berfungsi adalah jawaban UDP. Dua kueri DNS menjawab pertanyaan lain: jika resolver lokal dan resolver publik tidak sepakat soal alamat titik akhir, Anda sedang diarahkan dan argumen transport itu yang salah.

Verifikasi apa yang benar-benar meninggalkan mesin

Log klien menggambarkan apa yang klien yakini. Tangkapan menggambarkan apa yang dilihat jaringan, dan selisih keduanya adalah tempat sebagian besar kasus ini diselesaikan:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Jika Anda melihat paket SYN dan tidak ada SYN-ACK, blokirnya di hulu dan klien tidak bersalah. Jika Anda melihat jabat tangan selesai ke alamat yang bukan milik server, Anda berbicara dengan proksi atau penyadap. Jika Anda tidak melihat apa pun, periksa apakah Anda menangkap di antarmuka yang benar sebelum menyimpulkan apa pun.

Daftar soket menangkap kasus lebih halus: terowongan kedua yang sudah memegang rute bawaan. Dua klien yang berebut tabel perutean menghasilkan kegagalan berkala yang tampak persis seperti jaringan terblokir, dan tangkapan akan menunjukkan lalu lintas keluar lewat antarmuka yang tidak Anda duga.

Membatalkan, dan catatan yang layak disimpan

Batalkan perubahan dalam urutan terbalik dari cara Anda membuatnya. Hapus variabel proksi, hentikan klien yang Anda jalankan sendiri, dan hapus penimpaan rute atau resolver yang Anda tambahkan:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Membiarkan klien yang dijalankan sendiri tetap hidup adalah cara laptop berakhir dengan jaringan rusak pada kunjungan kantor berikutnya. Variabel proksi yang tertinggal di profil shell merusak alat tak terkait berminggu-minggu kemudian, dan orang yang men-debug-nya tidak akan menghubungkan kedua peristiwa.

Lalu tulis empat baris: jaringan, cap waktu, fase yang gagal, dan penerbit yang Anda lihat. Jalur yang berfungsi di satu kampus dan gagal di kampus berikutnya normal, dan orang berikutnya perlu tahu apakah selisihnya proksi, resolver, atau filter. Jika jawabannya bahwa jaringan melarang akses jarak jauh, berhentilah di situ dan mintalah rute yang didukung kepada administrator alih-alih membawa jalan pintas ke kebijakan yang belum Anda baca.