OpenVPN tidak menyambung di Wi-Fi hotel? Cuba TCP 443

Buka klien, tekan Sambung dan baca baris status bukannya dialog yang menyusul. Profil yang terhenti pada Menyambung atau Menunggu pelayan selepas rangkaian hotel, kampus atau mudah alih biasanya telah kehilangan pengangkutannya di suatu tempat di laluan, bukan kelayakannya. Langkah seterusnya yang berguna ialah mengetahui apa yang dibawa rangkaian itu sebelum menyentuh pelayan. Jangan ubah apa-apa sehingga profil yang sama berfungsi di tempat lain.

Uji dahulu dari titik akses telefon. Jika terowong muncul di sana, pelayan, sijil dan akaun semuanya baik, dan satu-satunya pemboleh ubah yang tinggal ialah rangkaian di hadapan anda.

Mulakan pada klien: baca baris status

Baris status memberitahu anda peringkat mana yang gagal. Klien yang tersangkut pada Menyambung masih menyelesaikan nama hos atau membuka soket luar; yang sampai ke Menunggu pelayan mempunyai laluan tetapi tiada balasan; yang mengesahkan diri dan kemudian terputus mempunyai masalah yang sama sekali berbeza. Log klien dan medan remote serta proto milik profil sendiri menunjukkan apa yang cuba dilakukan klien, dan --verb 4 pada klien baris arahan mencetak butiran yang sama. Membandingkannya dengan rangkaian di hadapan anda itulah yang menukar 'VPN disekat' menjadi dakwaan yang khusus.

Kemudian siasat rangkaian dengan alat yang sudah anda miliki. nc -vzu 203.0.113.10 1194 menghantar datagram UDP, curl -v telnet://203.0.113.10:443 melaporkan sama ada jabat tangan TCP selesai, dan pelayar yang memuatkan halaman HTTPS hanya membuktikan bahawa keluar 443 sampai ke hos tunggal itu. Siasatan kecil menjawab apa yang tidak dapat dijawab klien VPN: port dan protokol mana yang benar-benar keluar dari rangkaian ini.

Tiga tingkah laku rangkaian kelihatan serupa dari klien dan memerlukan jawapan berbeza. Keluar 443 mungkin terbuka, hanya proksi mungkin dibenarkan, atau 443 mungkin diposkan secara telus ke kotak pemeriksaan yang tidak dapat membaca apa yang dibawanya. Yang pertama diperbaiki oleh perubahan profil di bawah, yang kedua oleh tetapan proksi, dan yang ketiga mungkin menyelesaikan jabat tangan lalu terhenti apabila pemeriksa memutuskan ia tidak menyukai aliran itu. Mengetahui yang mana satu anda hadapi ialah perbezaan antara perubahan sepuluh minit dan sehari menghabiskan masa memasang semula klien.

Alihkan pendengar dan profil bersama-sama

Di sebelah pelayan, tetapkan pendengar kepada apa yang dibenarkan rangkaian: port 443 dan proto tcp dalam konfigurasi pelayan, kemudian mulakan semula perkhidmatan dan sahkan soket dengan ss -lntp. Di sebelah klien, profil mesti bersetuju, kerana pengangkutan dan port berada di luar terowong: proto tcp dan port 443 dalam .ovpn, atau medan yang sepadan pada skrin tetapan aplikasi. Profil yang masih menuju UDP 1194 gagal sama seperti sebelum ini, dan timbul godaan menyalahkan tembok api yang sudah dibaiki. Jika hos yang sama juga menjawab HTTPS pada 443, kedua-dua pendengar tidak boleh berkongsi alamat dan protokol itu; beri VPN alamat kedua atau letakkan demultiplekser di hadapan.

Perhatikan sambungan pertama dengan tcpdump -ni any port 443 di kedua-dua hujung. Paket yang meninggalkan klien dan tidak pernah tiba bermaksud rangkaian masih menapis, atau alamat dalam profil bukan yang anda andaikan. Paket yang tiba tanpa balasan menghantar anda kembali ke log pelayan, di mana ketidakpadanan protokol muncul serta-merta sebagai paket yang dibuang.

Apabila hanya proksi keluar dari rangkaian

Sesetengah rangkaian tetamu tidak membenarkan apa-apa kecuali proksi HTTP, yang merupakan kekangan berbeza daripada port tertutup dan mengecualikan lebih banyak daripada OpenVPN. Klien yang hanya bercakap PPTP, L2TP/IPsec atau IPsec kosong tiada jalan melaluinya, kerana reka bentuk itu menjangka protokol luar mereka sampai terus ke pelayan. OpenVPN boleh, dengan http-proxy proxy.example.net 8080 dalam profil klien, asalkan proksi membenarkan kaedah CONNECT ke port anda. Proksi SOCKS lebih mudah lagi, kerana ia memajukan aliran tanpa mengambil peduli apa yang ada di dalamnya.

Di mana klien tiada sokongan proksi, terowong SSH melalui 443 biasanya yang tinggal. Ia menambah lapisan kedua, dan pengendali rangkaian mungkin mempunyai pendapat tentangnya, jadi anggap ia sebagai jambatan untuk satu perjalanan dan bukan sebagai seni bina.

Nilaikan kos jalan sandaran sebelum mengekalkannya

TCP di dalam TCP mempunyai kos yang diketahui. Apabila sambungan luar ialah TCP dan muatan juga TCP, segmen yang hilang mencetuskan penghantaran semula pada kedua-dua lapisan, dan sambungan dalam berundur daripada kehilangan yang tidak dapat dilihatnya. Pelayaran bertahan; sesi interaktif dan panggilan merasakannya. Kekalkan pendengar TCP 443 sebagai sandaran untuk rangkaian yang menuntutnya, dan biarkan UDP sebagai lalai untuk semua yang masih melaluinya.

Catatkan pilihan itu dalam nama profil dan dalam nota sokongan: port mana, protokol mana dan rangkaian mana yang mencetuskannya. Kemudian tanya pentadbir rangkaian sama ada port itu kekal terbuka selepas penggantian peralatan seterusnya, kerana jalan sandaran yang hilang secara senyap lebih buruk daripada tiada jalan sandaran sama sekali.