VPN terhubung di rumah tetapi waktu habis di Wi-Fi hotel

Laptop bergabung ke Wi-Fi rumah, klien terhubung dalam tiga detik, dan profil yang sama gagal di hotel satu jam kemudian. Tidak ada yang diperbarui di antaranya. Menelusuri ini dengan klien di depan Anda terutama tentang mengetahui kesalahan mana milik tahap mana, karena informasi yang berguna ada pada kode yang dicetak klien, bukan pada kenyataan bahwa ia gagal. Jalankan empat langkah di bawah secara berurutan dan Anda akan tahu apakah nama, paket, port, atau kebijakan yang menolak Anda.

Bacalah kode kesalahan sebagai tahap, bukan putusan

Klien mencapai tiga tonggak terpisah sebelum terowongan ada. Ia menyelesaikan nama server, ia mendapat jawaban dari sesuatu di jaringan, dan ia menegosiasikan asosiasi keamanan. Setiap tonggak punya pesan kegagalannya sendiri, dan Windows khususnya murah hati dengan kode yang berbeda begitu Anda tahu kode itu milik tahap mana.

Dua dari kode itu berarti jaringan tidak bersalah. 789 berarti paket mengalir dan kedua ujung tidak sepakat soal kripto, yang merupakan masalah konfigurasi yang bisa Anda perbaiki di rumah. 868 berarti tidak ada paket yang perlu keluar, jadi desain terowongan tidak relevan sampai nama terselesaikan. Menempatkan kode pada tahap yang benar menghemat lebih banyak waktu daripada tangkapan apa pun, karena memberi tahu Anda langkah mana dari tiga langkah berikutnya yang bisa dilewati.

Bersikap hati-hati sewajarnya jika klien bukan Windows. Klien pihak ketiga merangkum sebagian besar ini menjadi "koneksi gagal", karena itu dua langkah berikutnya sama sekali tidak bergantung pada pesan.

Periksa nama sebelum menyalahkan terowongan

Jaringan hotel dan bandara terus mencegat DNS, dan resolver yang menjawab dengan alamat portal menghasilkan kegagalan yang tampak persis seperti server mati. Bandingkan apa yang dikatakan resolver lokal dengan apa yang dikatakan resolver publik:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Jika kedua jawaban berbeda, Anda sedang diarahkan dan sisa diagnosis sia-sia sampai itu diselesaikan. Alamat portal khususnya akan dengan senang hati menerima koneksi TCP lalu tersendat, karena itu bisa tampak seperti blokir firewall saat Anda menguji dengan peramban.

Sekarang pastikan alamat yang ingin Anda tuju adalah yang sedang dipakai. Beberapa klien menyimpan hasil resolusi sebelumnya selama seluruh usia profil, jadi menyambung ulang setelah perubahan DNS masih menuju alamat lama. Tutup klien sepenuhnya sebelum menguji ulang, bukan menekan putuskan lalu sambungkan di jendela yang sama.

Cari tahu paket luar mana yang hilang

Terowongan punya aliran luar yang sepenuhnya milik jalur antara Anda dan server, dan aliran itulah yang diklasifikasikan dan dijatuhkan oleh kotak perantara. Tangkap di klien, lalu bandingkan jaringan yang berfungsi dengan yang gagal. Di Windows tangkapan bawaan cukup untuk pandangan pertama:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Yang ingin Anda lihat adalah apakah paket Anda keluar sama sekali, dan apakah ada yang kembali. Paket keluar tanpa balasan berarti jalur atau ujung jauh menjatuhkannya; jika tidak ada yang keluar sama sekali, klien tidak pernah sampai mengirim, yang menunjuk kembali ke resolusi nama atau ke kebijakan firewall lokal.

Ulangi pengujian yang sama di hotspot ponsel. Ini adalah perbandingan paling informatif yang tersedia bagi Anda, karena menghapus setiap kotak di hotel dari jalur sambil menjaga laptop, klien, dan kredensial tetap sama. Jika terowongan muncul di hotspot, berhentilah melihat server. Jika juga gagal di sana, Anda punya masalah klien atau akun yang tidak pernah disebabkan jaringan.

Ganti satu transport dan uji ulang

Begitu Anda tahu aliran luar dijatuhkan, pertanyaan praktisnya adalah aliran mana yang diizinkan jaringan. Sebagian besar jaringan terbatas mengizinkan TCP 443 keluar karena mereka tidak dapat berfungsi tanpanya, jadi memindahkan pendengar ke sana adalah jawaban yang biasa. Pada OpenVPN itu adalah sakelar sisi klien sampai server diubah:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

Klien IPsec punya tombol setara di panel pengaturannya sendiri, biasanya dijelaskan sebagai IPsec melalui TCP atau NAT traversal. Mengubahnya juga sebuah diagnosis: jika terowongan muncul melalui TCP dan mati melalui UDP, Anda telah membuktikan jaringan menyaring UDP, dan Anda juga telah menemukan pengaturan yang Anda butuhkan setiap kali mengunjungi situs itu.

Tahan godaan untuk mematikan fitur router pada percobaan pertama. Mematikan inspeksi stateful atau perlindungan banjir di jaringan hotel tidak tersedia bagi Anda, dan pada peralatan Anda sendiri itu menukar perlindungan nyata dengan satu laptop. Catat pengaturan mana yang mengubah hasil, lalu kembalikan dan cari transport yang sudah diizinkan jaringan.

Verifikasi profil yang sama di jaringan kedua

Sebelum menutup tiket, buktikan perubahan itu bertahan setelah meninggalkan gedung. Sambungkan ulang di jaringan asli dengan pengaturan asli, tangkap tiga puluh detik pertama, dan pastikan klien mencapai keadaan yang sama seperti di hotspot:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Perbedaan yang diungkap perintah terakhir layak dipertahankan: profil dapat melaporkan terowongan tersambung sementara perutean di dalamnya salah, dan itu menghasilkan "VPN menyala tetapi tidak ada yang berfungsi", yang merupakan artikel lain. Jika jenis terowongan berubah setelah suntingan Anda, profil itu bukan yang Anda uji.

Lalu tulis temuan di tempat orang berikutnya akan melihat. "Profil korporat memerlukan TCP 443 di situs ini; UDP 500 disaring oleh hotel" adalah kalimat yang bisa ditindaklanjuti kolega. "VPN tidak stabil di hotel" bukan, dan itu menjamin jam yang sama akan terbuang lagi bulan depan.