VPN disekat pada rangkaian web sahaja? Kerjakan lapisannya

Rangkaian kampus atau hotel tempat pelayar berfungsi dan setiap terowong mati bukan satu masalah, tetapi empat bertindan. Laluan itu mungkin hanya membenarkan TCP 443, menuntut proksi disahkan, memeriksa jabat tangan, atau sekadar melarang akses jauh melalui dasar. Menanganinya mengikut urutan menghalang anda membeli klien baharu untuk membaiki peraturan rangkaian. Panduan di bawah mengambil masa kira-kira sepuluh minit dan berakhir dengan jawapan bertulis tentang lapisan mana yang menolak anda.

Buktikan lapisan mana yang menolak sambungan

Jangan mulakan dengan klien VPN. Mulakan dengan permintaan HTTPS biasa ke hos yang sama dan baca fasa masa, kerana fasa yang gagal memberitahu peranti mana yang bertanggungjawab:

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

Tiada respons dan tiada masa connect bermakna TCP tidak pernah selesai, jadi tembok api, keperluan proksi atau destinasi salah sedang bermain. Masa connect tanpa masa tls bermakna sesuatu di tengah menerima sambungan lalu menghentikan jabat tangan, dan begitulah rupa proksi pemeriksa dari sisi klien.

Sekarang periksa sijil yang benar-benar anda terima. Ini cara terpantas mengetahui sama ada anda bercakap dengan pelayan atau dengan kotak perantaraan yang menandatangani semula sesi:

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

Baca baris pengeluar. CA anda sendiri bermakna anda sampai ke perkhidmatan; pengeluar korporat atau peranti bermakna penapis menamatkan sambungan dan menentukan apa yang berlaku seterusnya. Rekod kedua-dua output dengan cap masa, kerana ujian yang sama sejam kemudian di rangkaian tetamu mungkin memberi jawapan berbeza.

Klien yang sedar proksi menukar paket pertama, bukan dasar

Jika rangkaian menuntut CONNECT melalui proksi disahkan, klien VPN perlu diberitahu, jika tidak ia akan cuba membuka soket ke alamat yang tidak dapat dihalakan. Uji proksi berasingan daripada klien, supaya kegagalan mempunyai 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 destinasi. Yang kedua meminta klien menggunakan TCP pada 443, satu-satunya pengangkutan yang kebanyakan laluan web sahaja akan teruskan. Jika yang pertama berjaya dan yang kedua masih gagal, proksi bukan penghalang.

Sesetengah klien membaca proksi sistem pengendalian dan bukan penggantian, dan sesetengah tidak membaca kedua-duanya. Semak dokumentasi aplikasi sebelum menganggap tetapan seluruh sistem terpakai. Klien yang menyelesaikan titik akhir melalui penyelesai yang tidak dilayani proksi juga akan gagal di sini, dan itulah sebabnya perubahan DNS boleh kelihatan seperti pembaikan padahal ia hanya lencongan.

Perhatikan juga corak pengarahan. Rangkaian yang ditapis boleh menjawab nama hos pengesanan vendor dengan sesuatu miliknya sendiri, yang mengubah profil proksi yang dipilih klien. Jangan bina proses di sekeliling keanehan itu. Ia berbeza mengikut tapak, berubah tanpa notis, dan bukan sesuatu yang boleh anda sokong untuk orang lain.

Port 443 boleh dicapai, bukan dibenarkan

Membalut terowong dalam TLS pada 443 menyelesaikan kebolehcapaian dan tidak lebih. Penapis yang memeriksa port akan meloloskannya; penapis yang mengambil cap jari jabat tangan tidak, dan sapaan klien disulitkan hanya menyembunyikan nama pelayan apabila kedua-dua hujung menyokongnya. Jalankan ujian dan ketahui jenis penapis yang berada di hadapan anda daripada berharap.

Ada juga kos prestasi yang orang temui kemudian. Pengangkutan boleh dipercayai di dalam pengangkutan boleh dipercayai menguatkan kehilangan, kerana tindanan dalam menghantar semula segmen yang tindanan luar sudah hantar semula. Pada pautan bersih tiada siapa perasan. Pada rangkaian wayarles kampus yang sesak terowong menjadi tidak boleh digunakan tepat apabila anda memerlukannya, dan graf kelihatan seperti kehilangan paket walaupun tiada yang digugurkan dengan sengaja.

UDP biasanya mangsa pertama, dan itu wajar disahkan bukan diagak. Jika WireGuard atau OpenVPN lalai tidak pernah menyelesaikan jabat tangan sementara TCP 443 berfungsi, rangkaian menggugurkan UDP, dan tiada penjanaan semula kunci akan mengubahnya:

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

Cap masa jabat tangan kosong di sebelah rakan yang berfungsi semalam ialah jawapan UDP. Dua pertanyaan DNS menjawab soalan lain: jika penyelesai tempatan dan penyelesai awam tidak bersetuju tentang alamat titik akhir, anda sedang diarahkan dan hujah pengangkutan itu yang salah.

Sahkan apa yang benar-benar meninggalkan mesin

Log klien menggambarkan apa yang klien percaya. Tangkapan menggambarkan apa yang rangkaian lihat, dan perbezaan antara keduanya ialah tempat kebanyakan kes 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 tiada SYN-ACK, sekatan berada di hulu dan klien tidak bersalah. Jika anda melihat jabat tangan selesai ke alamat yang bukan milik pelayan, anda bercakap dengan proksi atau pemintas. Jika anda tidak melihat apa-apa, semak sama ada anda menangkap pada antara muka yang betul sebelum membuat kesimpulan.

Senarai soket menangkap kes yang lebih halus: terowong kedua yang sudah memegang laluan lalai. Dua klien yang berebut jadual penghalaan menghasilkan kegagalan berselang yang kelihatan tepat seperti rangkaian disekat, dan tangkapan akan menunjukkan trafik keluar melalui antara muka yang anda tidak jangkakan.

Membatalkan, dan nota yang wajar disimpan

Batalkan perubahan dalam susunan terbalik daripada cara anda membuatnya. Buang pemboleh ubah proksi, hentikan klien yang anda mulakan secara manual, dan keluarkan sebarang penggantian laluan atau penyelesai yang anda tambah:

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

Membiarkan klien yang dimulakan secara manual berjalan ialah cara komputer riba berakhir dengan rangkaian rosak pada lawatan pejabat seterusnya. Pemboleh ubah proksi yang ditinggalkan dalam profil shell merosakkan alat tidak berkaitan berminggu-minggu kemudian, dan orang yang menyahpepijatnya tidak akan menghubungkan kedua-dua peristiwa.

Kemudian tulis empat baris: rangkaian, cap masa, fasa yang gagal, dan pengeluar yang anda lihat. Laluan yang berfungsi di satu kampus dan gagal di kampus seterusnya adalah normal, dan orang seterusnya perlu tahu sama ada perbezaannya proksi, penyelesai atau penapis. Jika jawapannya rangkaian melarang akses jauh, berhenti di situ dan minta laluan yang disokong daripada pentadbir daripada membawa jalan pintas ke dasar yang belum anda baca.