OpenVPN tidak tersambung di Wi-Fi hotel? Coba TCP 443

Buka klien, tekan Sambungkan, dan baca baris status alih-alih dialog yang muncul setelahnya. Profil yang mandek di Menyambung atau Menunggu server setelah jaringan hotel, kampus, atau seluler biasanya kehilangan transportnya di suatu titik pada jalur, bukan kredensialnya. Langkah berikut yang berguna adalah mempelajari apa yang dibawa jaringan itu sebelum menyentuh server. Jangan ubah apa pun sampai profil yang sama berhasil di tempat lain.

Uji dulu dari hotspot ponsel. Jika terowongan muncul di sana, server, sertifikat, dan akun semuanya baik-baik saja, dan satu-satunya variabel yang tersisa adalah jaringan di depan Anda.

Mulai dari klien: baca baris status

Baris status memberi tahu Anda tahap mana yang gagal. Klien yang macet di Menyambung masih menyelesaikan nama host atau membuka soket luar; yang sampai ke Menunggu server punya jalur tetapi tidak ada balasan; yang berhasil mengautentikasi lalu putus punya masalah yang sama sekali berbeda. Log klien dan bidang remote serta proto milik profil sendiri menunjukkan apa yang coba dilakukan klien, dan --verb 4 pada klien baris perintah mencetak detail yang sama. Membandingkan itu dengan jaringan di depan Anda adalah yang mengubah 'VPN diblokir' menjadi klaim yang spesifik.

Lalu uji jaringan dengan alat yang sudah Anda punya. nc -vzu 203.0.113.10 1194 mengirim datagram UDP, curl -v telnet://203.0.113.10:443 melaporkan apakah jabat tangan TCP selesai, dan peramban yang memuat halaman HTTPS hanya membuktikan bahwa keluar 443 mencapai satu host itu. Uji kecil menjawab apa yang tidak bisa dijawab klien VPN: port dan protokol mana yang benar-benar keluar dari jaringan ini.

Tiga perilaku jaringan tampak serupa dari klien dan membutuhkan jawaban berbeda. Keluar 443 mungkin terbuka, hanya proksi yang diizinkan, atau 443 diteruskan secara transparan ke kotak inspeksi yang tidak dapat membaca apa yang dibawanya. Yang pertama diperbaiki oleh perubahan profil di bawah, yang kedua oleh pengaturan proksi, dan yang ketiga dapat menyelesaikan jabat tangan lalu mandek ketika inspektur memutuskan tidak menyukai alirannya. Mengetahui mana yang Anda hadapi adalah perbedaan antara perubahan sepuluh menit dan seharian memasang ulang klien.

Pindahkan listener dan profil bersama-sama

Di sisi server, atur listener ke apa yang diizinkan jaringan: port 443 dan proto tcp dalam konfigurasi server, lalu mulai ulang layanan dan pastikan soket dengan ss -lntp. Di sisi klien, profil harus setuju, karena transport dan port berada di luar terowongan: proto tcp dan port 443 di .ovpn, atau bidang yang sesuai di layar pengaturan aplikasi. Profil yang masih diarahkan ke UDP 1194 gagal persis seperti sebelumnya, dan muncul godaan menyalahkan firewall yang sudah diperbaiki. Jika host yang sama juga menjawab HTTPS pada 443, kedua listener tidak dapat berbagi alamat dan protokol itu; beri VPN alamat kedua atau taruh demultiplekser di depan.

Awasi koneksi pertama dengan tcpdump -ni any port 443 di kedua ujung. Paket yang meninggalkan klien dan tidak pernah tiba berarti jaringan tetap menyaring, atau alamat di profil bukan yang Anda anggap. Paket yang tiba tanpa balasan mengirim Anda kembali ke log server, di mana ketidakcocokan protokol langsung muncul sebagai paket yang dibuang.

Ketika hanya proksi yang keluar dari jaringan

Beberapa jaringan tamu tidak mengizinkan apa pun kecuali proksi HTTP, yang merupakan batasan berbeda dari port tertutup dan menyingkirkan lebih banyak daripada OpenVPN. Klien yang hanya berbicara PPTP, L2TP/IPsec, atau IPsec polos tidak punya jalan melewatinya, karena rancangan itu mengharapkan protokol luarnya mencapai server secara langsung. OpenVPN bisa, dengan http-proxy proxy.example.net 8080 di profil klien, asalkan proksi mengizinkan metode CONNECT ke port Anda. Proksi SOCKS bahkan lebih mudah, karena meneruskan aliran tanpa peduli apa isinya.

Di mana klien tidak punya dukungan proksi, terowongan SSH melalui 443 biasanya yang tersisa. Itu menambah lapisan kedua, dan operator jaringan mungkin punya pendapat tentangnya, jadi perlakukan sebagai jembatan untuk satu perjalanan alih-alih sebagai arsitektur.

Hitung biaya cadangan sebelum mempertahankannya

TCP di dalam TCP punya biaya yang sudah dikenal. Ketika koneksi luar adalah TCP dan muatannya juga TCP, segmen yang hilang memicu pengiriman ulang di kedua lapisan, dan koneksi dalam mundur dari kehilangan yang tidak dapat dilihatnya. Penjelajahan bertahan; sesi interaktif dan panggilan merasakannya. Pertahankan listener TCP 443 sebagai cadangan untuk jaringan yang menuntutnya, dan biarkan UDP sebagai bawaan untuk semua yang masih meloloskannya.

Catat pilihan itu di nama profil dan di catatan dukungan: port mana, protokol mana, dan jaringan mana yang menyebabkannya. Lalu tanyakan kepada administrator jaringan apakah port itu tetap terbuka setelah penggantian peralatan berikutnya, karena cadangan yang hilang diam-diam lebih buruk daripada tidak ada cadangan sama sekali.