Mengapa profil OpenVPN berfungsi di rumah tetapi gagal di hotel

Wi-Fi kantor dan kamar hotel dapat memberikan dua jaringan yang sangat berbeda kepada laptop yang sama, dan profil di antaranya tidak tahu apa-apa soal itu. Yang berfungsi di rumah mengandaikan uplink yang permisif, resolusi nama yang bekerja, dan subnet lokal yang tidak bentrok dengan apa pun yang dibawa tunnel. Setiap asumsi itu dapat gagal secara terpisah.

Cara berguna untuk men-debug ini adalah memperlakukan jaringan sebagai empat fakta terpisah, lalu mengujinya berurutan. Menebak profil lebih dulu biasanya menghasilkan perubahan yang tidak memperbaiki apa pun dan menyamarkan bukti.

Empat fakta jaringan berubah antar lokasi

Fakta pertama adalah apakah jaringan lokal mengizinkan Anda keluar sama sekali. Portal masuk menerima perangkat ke halaman login dan memblokir semua yang lain sampai halaman itu selesai, yang berarti tunnel tidak bisa dimulai, seberapa pun benar profilnya.

Fakta kedua adalah resolusi nama. Portal yang mencegat DNS menjawab setiap kueri dengan alamatnya sendiri, sehingga nama host VPN ter-resolve ke portal dan klien mencoba membangun tunnel ke halaman web.

Fakta ketiga adalah penyaringan transport. Jaringan yang hanya ingin mengizinkan penjelajahan meneruskan TCP 443 ke tujuan sembarang dan menjatuhkan hampir semua yang lain, termasuk UDP.

Fakta keempat adalah pengalamatan. Subnet lokal dapat tumpang tindih dengan jaringan di balik tunnel, atau uplink tidak menyediakan jalur IPv4 yang dapat dipakai sama sekali.

Resolusi nama dan portal masuk

Ganti nama host di profil dengan alamat numerik server dan coba lagi. Jika IP terhubung dan namanya tidak, resolusilah penyebabnya, dan profilnya sendiri baik-baik saja.

Buka peramban dan coba halaman HTTP biasa sebelum menyentuh VPN. Pengalihan ke halaman login berarti portal masih tertunda; selesaikan, lalu sambungkan ulang. Banyak hotel juga mengakhiri sesi setelah beberapa jam, yang terlihat seperti pemutusan tengah hari, bukan masalah login.

Jika alamat numerik juga gagal, resolusi bukan penjelasannya, jadi beralihlah ke transport. Simpan alamat yang Anda uji, karena itu memberi tahu pemeriksaan berikutnya apakah paket meninggalkan mesin sama sekali.

Penyaringan transport: UDP lebih dulu, TCP 443 sebagai cadangan

Aliran OpenVPN melalui UDP 1194 tidak tampak seperti apa pun yang dikenali firewall hotel, jadi dijatuhkan tanpa galat. Klien mencoba lagi sampai batas waktunya habis, dan pengguna melihat koneksi yang tidak pernah terbentuk, bukan penolakan. Firewall yang berperilaku begitu jarang mencatat penjatuhan di tempat yang bisa Anda lihat. Tidak adanya penolakan itu sendiri adalah petunjuknya.

TCP 443 adalah cadangan yang andal karena jaringan tidak dapat membedakannya dari HTTPS biasa. Gunakan profil TCP operator bila ada, karena server juga harus mendengarkan pada transport dan port itu; mengubah klien saja menghasilkan jenis kegagalan lain. Jika tidak ada profil TCP, tanyakan kepada operator alih-alih mengarangnya dengan mengedit port. Sisi server harus setuju, dan ketidakcocokan terlihat seperti masalah firewall lagi.

Perkirakan biaya kinerja. TCP di dalam TCP memperkuat pengiriman ulang pada tautan yang rawan kehilangan, sehingga tunnel TCP yang berfungsi tetap bisa terasa lambat di jaringan hotel yang padat. Itu adalah tukar demi keterjangkauan, bukan cacat yang harus dikejar.

Bentrokan alamat dan uplink tanpa IPv4

Tunnel dapat terbentuk dan tetap tidak mengangkut apa pun. Ketika LAN lokal dan jaringan jauh berbagi prefiks seperti 192.168.1.0/24, klien menganggap host jauh tersambung langsung dan mengirim paket ke tautan lokal alih-alih tunnel. Gejalanya adalah koneksi yang berhasil dengan satu subnet tak terjangkau, yang mudah disalahbaca sebagai masalah rute di sisi server.

Perbaikan permanennya adalah memindahkan LAN jauh ke rentang privat yang tidak lazim. Memilih rentang yang tidak dipakai siapa pun di rumah, seperti 10.42.0.0/24, mencegah masalah untuk setiap lokasi mendatang alih-alih satu. Akal-akalan lokalnya adalah menghindari hotel, hotspot, atau router itu, yang sama sekali bukan perbaikan.

Uplink seluler menambahkan dua variasi. NAT tingkat operator berarti koneksi masuk tidak tiba, yang penting bila Anda meng-host server tetapi tidak untuk klien keluar. APN yang dikonfigurasi hanya IPv6 dengan terjemahan NAT64 dapat menggagalkan klien yang menuntut jalur IPv4 nyata, dan obat biasanya adalah mengubah protokol APN ke IPv4 atau tumpukan ganda.

Gejala setelah tunnel menyala

Tunnel yang tersambung lalu diam biasanya masalah keepalive atau MTU, bukan port yang diblokir. Koneksi yang putus setelah jumlah menit tetap menunjuk pada timer keepalive atau negosiasi ulang. Atur klien untuk menyelidiki pasangannya dan memulai ulang saat balasan berhenti, dan uji MTU tunnel yang lebih kecil jika ping berhasil sementara transfer besar macet.

Sebelum meminta bantuan, tuliskan tiga hal: alamat yang Anda coba dan apakah ia menjawab, transport dan port yang Anda gunakan, serta subnet lokal jaringan yang gagal. Bersama-sama semuanya memisahkan resolusi nama dari penyaringan transport dan dari bentrokan alamat, yaitu penyebab yang bertahan saat berhadapan dengan bukti.