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

Profil yang sama bersambung dari rumah dan terhenti pada rangkaian hotel, kampus atau cawangan. Kredensial tidak berubah, jadi pemboleh ubah yang menarik ialah laluan: apa yang berlaku kepada paket sebelum OpenVPN membacanya. Membandingkan empat punca calon mengikut urutan yang boleh diuji lebih baik daripada meneka tentang sijil. Setiap satu meninggalkan jejak berbeza, dan jejak itulah yang memisahkannya.

Peringkat mana yang gagal memberitahu perbandingan mana yang penting

Log klien sudah merekodkan sejauh mana anda pergi. Baris yang menyatakan rundingan kunci TLS tidak berlaku dalam had masa bermakna paket pertama keluar dan tiada balasan berguna kembali, yang menunjuk kepada laluan. Penolakan sijil kelihatan sama sekali berbeza: balasan tiba, kemudian ralat pengesahan tertentu menyebut puncanya. Catat baris terakhir sebelum gelung cuba semula, kerana itulah nilai yang anda bandingkan antara rangkaian.

Tangkap semasa mencuba semula, bukan selepasnya. Pada klien, tcpdump -ni any udp port 1194 menunjukkan sama ada sebarang balasan kembali. Ulangi pada antara muka WAN pelayan yang anda kawal, yang mendedahkan sama ada paket itu sampai ke hujung jauh.

Trafik sehala ialah hasil paling berguna yang tersedia di sini, kerana ia mengubah aduan berselang-seli menjadi arah untuk disiasat. Simpan fail tangkapan, kerana laporan masalah yang sama seterusnya lebih mudah ditutup dengan bukti daripada dengan penerangan.

Penapisan UDP berbanding port tertutup

Banyak rangkaian akses menganggap UDP berterusan sebagai mencurigakan, dan sesetengah ISP bersetuju. Port tertutup menghasilkan kesunyian yang sama dari sisi klien. Bezanya ialah selektiviti: penapis cenderung memilih destinasi atau port mana yang digugurkan, manakala port tertutup menolak segala-galanya yang ditujukan ke port itu.

Profil TCP pada port 443 ialah penyelesaian biasa, kerana ia menyerupai aliran HTTPS biasa dan melepasi kebanyakan portal captive dan penapis keluar. Dua syarat mesti dipenuhi. Pelayan mesti mendengar dengan proto tcp-server dan klien mesti sepadan dengan proto tcp-client, dan pengendali mesti menerbitkan titik akhir alternatif itu. Menulis semula profil UDP yang berfungsi untuk mendakwa TCP 443 tidak membawa ke mana-mana apabila tiada apa yang mendengar di hujung sana.

Port tertutup ialah masalah konfigurasi, bukan masalah penapisan. Pelayan di belakang penghala rumah memerlukan port UDP-nya diposkan, dan firewall penghala mesti membenarkannya. Apabila port itu tidak pernah dibenarkan, setiap klien gagal pada rundingan tanpa mengira kredensial, dan kegagalan mengikut pelayan, bukan rangkaian.

Protokol lama tidak setanding pada paksi ini. PPTP memerlukan TCP 1723 serta GRE, dan GRE ialah protokol IP 47, bukan port, jadi tiada pemposan port biasa dapat menyatakannya.

Apabila suis yang menggugurkan paket

Suis terurus boleh menggugurkan terowong dengan sengaja. Sesetengah model HPE dan Aruba mendedahkan kawalan perlindungan banjir UDP, kadangkala dilabel Prevent UDP Blat Attack, dalam bahagian keselamatan lanjutan mereka. Setelah kawalan itu aktif, pelayan di belakang suis tidak menjawab apa-apa dan setiap klien tamat masa dengan cara yang sama. Mengosongkannya dan menyimpan konfigurasi yang berjalan ialah keseluruhan pembaikan, tetapi hanya selepas anda memastikan suis itu benar-benar berada di laluan.

Bukti berlawanan ialah yang memisahkan guguran suis daripada sekatan penyedia. Baca pembilang antara muka dan log perlindungan banjir sebelum membuka tiket dengan ISP. Penghala pengguna dengan perlindungan DoS atau banjir gagal dalam bentuk yang sama, dan begitu juga mana-mana middlebox dengan had masa melahu UDP yang pendek. Jabat tangan yang tidak pernah selesai mencadangkan guguran, manakala terowong yang mati selepas beberapa minit senyap mencadangkan had masa.

Tuliskan setiap peranti antara klien dan pelayan sebelum menukar profil. Pembaikan yang digunakan pada lapisan yang salah kelihatan betul sehingga rangkaian seterusnya. Senarai itu juga memberitahu jurutera seterusnya di mana hendak melihat tanpa mengulangi keseluruhan siasatan.

Pertindihan alamat yang kelihatan seperti kegagalan DNS

Rangkaian akses yang bernombor dalam 10.0.0.0/8 boleh bertindih dengan kolam terowong, dan penyelesai biasanya berada di dalam kolam itu. Apabila komputer riba menerima alamat seperti 10.184.178.50 dengan topeng /8 pada Wi-Fi, setiap destinasi 10.x adalah setempat mengikut takrifan. Paket untuk 10.4.0.1 kemudian pergi ke LAN, terowong kekal berjalan, dan penyelesaian nama gagal.

ip addr mendedahkan pertindihan itu secara sekilas pandang, dan ip route get 10.4.0.1 menunjukkan ke mana paket itu sebenarnya akan dihantar. Kerana gejala yang kelihatan ialah kegagalan penyelesai, yang ini sering bertahan melalui beberapa pusingan perubahan DNS.

Nomborkan semula kolam itu atau kekalkan rangkaian akses itu di luar skop. Tiada tetapan sebelah klien yang pulih daripada pertindihan.

Memilih antara sandaran TCP dan pembaikan laluan

Pilih sandaran TCP apabila anda tidak mengawal laluan dan pengguna perlu bekerja hari ini, dan terima kosnya: TCP di dalam TCP berkelakuan buruk pada pautan yang rugi, dan sandaran itu memerlukan listener yang anda kendalikan. Pilih pembaikan laluan apabila sekatan itu terletak pada infrastruktur milik anda, kerana peraturan firewall lebih murah daripada listener kedua. Sama ada cara, lalui lapisan mengikut urutan: pautan, pengangkutan luar, rundingan, penghalaan dalaman. Peringkat yang gagal pada rangkaian itu ialah satu-satunya fakta yang penting.

Rekod hasil mengikut rangkaian, bukan mengikut pengguna. Laporan seterusnya tentang kegagalan yang sama kemudian bermula dari peringkat yang diketahui dan bukannya daripada teori sijil. Rekod itulah juga yang mewajarkan listener kedua yang kekal, jika ia pernah diperlukan.