OpenVPN berfungsi di rumah tetapi tidak di satu jaringan: UDP atau TCP?

Profil yang sama tersambung dari rumah dan macet di jaringan hotel, kampus, atau cabang. Kredensial tidak berubah, jadi variabel yang menarik adalah jalurnya: apa yang terjadi pada paket sebelum OpenVPN membacanya. Membandingkan empat kemungkinan penyebab sesuai urutan yang bisa diuji lebih baik daripada menebak soal sertifikat. Masing-masing meninggalkan jejak berbeda, dan jejak itulah yang membedakannya.

Tahap mana yang gagal menentukan perbandingan mana yang penting

Log klien sudah mencatat sejauh mana Anda berhasil. Baris yang menyatakan negosiasi kunci TLS gagal terjadi dalam batas waktu berarti paket pertama keluar dan tidak ada balasan yang bisa dipakai, yang menunjuk ke jalur. Penolakan sertifikat sama sekali tidak seperti itu: balasan datang, lalu kesalahan verifikasi tertentu menyebutkan alasannya. Catat baris terakhir sebelum loop percobaan ulang, karena itulah nilai yang Anda bandingkan antarjaringan.

Ambil tangkapan saat mencoba ulang, bukan sesudahnya. Pada klien, tcpdump -ni any udp port 1194 menunjukkan apakah ada balasan yang kembali sama sekali. Ulangi di antarmuka WAN server yang Anda kendalikan, yang mengungkap apakah paket itu sampai ke ujung jauh.

Lalu lintas satu arah adalah hasil paling berguna di sini, karena mengubah keluhan intermiten menjadi arah penyelidikan. Simpan berkas tangkapan, karena laporan berikutnya atas masalah yang sama lebih mudah ditutup dengan bukti daripada dengan deskripsi.

Penyaringan UDP versus port tertutup

Banyak jaringan akses menganggap UDP berkelanjutan mencurigakan, dan sebagian ISP setuju. Port tertutup menghasilkan kesunyian yang sama dari sisi klien. Bedanya adalah selektivitas: filter cenderung pemilih soal tujuan atau port mana yang dijatuhkan, sedangkan port tertutup menolak semua yang diarahkan ke port itu.

Profil TCP pada port 443 adalah solusi biasa, karena mirip aliran HTTPS biasa dan lolos dari sebagian besar portal captive dan filter keluar. Dua syarat harus terpenuhi. Server harus mendengarkan dengan proto tcp-server dan klien harus cocok dengan proto tcp-client, dan operator harus menerbitkan endpoint alternatif itu. Menulis ulang profil UDP yang berfungsi menjadi klaim TCP 443 tidak berguna jika tidak ada yang mendengarkan di ujung sana.

Port tertutup adalah masalah konfigurasi, bukan masalah penyensoran. Server di belakang router rumah perlu port UDP-nya diteruskan, dan firewall router harus mengizinkannya. Jika port itu tidak pernah diizinkan, setiap klien gagal pada negosiasi terlepas dari kredensial, dan kegagalan mengikuti server, bukan jaringan.

Protokol lama kalah dalam perbandingan pada sumbu ini. PPTP memerlukan TCP 1723 ditambah GRE, dan GRE adalah protokol IP 47, bukan port, sehingga tidak ada penerusan port biasa yang menyatakannya.

Ketika switch-lah yang menjatuhkan paket

Switch terkelola dapat menjatuhkan tunnel dengan sengaja. Beberapa model HPE dan Aruba menampilkan kontrol perlindungan banjir UDP, kadang diberi label Prevent UDP Blat Attack, di bagian keamanan lanjutan. Begitu kontrol itu aktif, server di belakang switch tidak menjawab apa pun dan setiap klien kehabisan waktu dengan cara yang sama. Menghapusnya dan menyimpan konfigurasi berjalan adalah seluruh perbaikannya, tetapi hanya setelah Anda memastikan switch benar-benar ada di jalur.

Bukti tandingan adalah yang membedakan paket yang dijatuhkan switch dari blokir penyedia. Baca penghitung antarmuka dan log perlindungan banjir sebelum membuka tiket ke ISP. Router konsumen dengan perlindungan DoS atau banjir gagal dengan bentuk yang sama, begitu juga middlebox mana pun dengan batas waktu idle UDP yang pendek. Handshake yang tidak pernah selesai menunjukkan penjatuhan, sedangkan tunnel yang mati setelah beberapa menit sepi menunjukkan batas waktu.

Tuliskan setiap perangkat antara klien dan server sebelum mengubah profil. Perbaikan yang diterapkan pada lapisan yang salah tampak benar sampai jaringan berikutnya. Daftar itu juga memberi tahu insinyur berikutnya ke mana harus melihat tanpa mengulang seluruh penyelidikan.

Tumpang tindih alamat yang tampak seperti kegagalan DNS

Jaringan akses yang diberi nomor di dalam 10.0.0.0/8 dapat tumpang tindih dengan kumpulan tunnel, dan resolver biasanya berada di dalam kumpulan itu. Ketika laptop menerima alamat seperti 10.184.178.50 dengan mask /8 di Wi-Fi, setiap tujuan 10.x bersifat lokal menurut definisi. Paket untuk 10.4.0.1 lalu menuju LAN, tunnel tetap hidup, dan resolusi nama gagal.

ip addr memperlihatkan tumpang tindih itu sekilas, dan ip route get 10.4.0.1 menunjukkan ke mana paket sebenarnya akan dikirim. Karena gejala yang terlihat adalah kegagalan resolver, masalah ini sering bertahan melewati beberapa putaran perubahan DNS.

Nomori ulang kumpulan alamat atau keluarkan jaringan akses itu dari cakupan. Tidak ada pengaturan sisi klien yang memulihkan dari tumpang tindih.

Memilih antara cadangan TCP dan perbaikan jalur

Pilih cadangan TCP ketika Anda tidak mengendalikan jalur dan pengguna perlu bekerja hari ini, dan terima biayanya: TCP di dalam TCP berperilaku buruk pada tautan yang lossy, dan cadangan itu memerlukan listener yang Anda operasikan. Pilih perbaikan jalur ketika blokir berada pada infrastruktur milik Anda, karena aturan firewall lebih murah daripada listener kedua. Bagaimanapun, telusuri lapisan secara berurutan: tautan, transport luar, negosiasi, perutean dalam. Tahap yang gagal pada jaringan itu adalah satu-satunya fakta yang penting.

Catat hasilnya per jaringan, bukan per pengguna. Laporan berikutnya atas kegagalan yang sama kemudian dimulai dari tahap yang diketahui, bukan dari teori sertifikat. Catatan itu juga yang membenarkan listener kedua yang permanen, jika suatu saat diperlukan.