OpenVPN pada port 53: tiga perbualan yang orang keliru
Carian titik akhir, pengangkutan disulitkan dan DNS selepas terowong ialah tiga perbualan. Kenal pasti peringkat mana yang gagal sebelum menukar port atau penyelesai.
Laporan yang mengatakan VPN disekat pada port 53 mencampurkan tiga pemerhatian yang gagal atas sebab berbeza. Penyelesaian nama titik akhir berlaku sebelum terowong wujud, pengangkutan disulitkan ialah perbualan berasingan, dan pertanyaan DNS yang dibuat selepas itu ialah yang ketiga. Setiap satu mempunyai tanda kegagalannya sendiri, dan hanya satu daripadanya berkaitan DNS.
Susun paket mengikut tujuan sebelum menukar apa-apa, kerana pembetulan mengikut peringkat.
Tiga perbualan, satu nombor port
Perbualan pertama ialah carian nama untuk titik akhir: mesin anda bertanya kepada penyelesai yang dikonfigurasikan di mana vpn.example.com berada, dan jawapan itu tiba melalui DNS biasa sebelum klien menghantar satu paket terowong pun. Yang kedua ialah pengangkutan OpenVPN itu sendiri, yang bersambung ke alamat yang dihasilkan oleh carian pada protokol dan port yang dinamakan oleh profil. Yang ketiga berlaku selepas terowong naik, apabila aplikasi meminta nama dan tetapan penyelesai yang ditolak menentukan siapa yang menjawab.
Ketiga-tiganya boleh berjaya atau gagal secara berasingan. Klien boleh menyelesaikan titik akhirnya dengan sempurna tetapi masih gagal mencapai pendengar, dan ia boleh membina terowong sementara setiap carian nama dalaman gagal kerana tetapan DNS tidak pernah tiba.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Baca jadual itu sebagai senarai semak, bukan sebagai huraian. Jika nama titik akhir tidak diselesaikan, tiada apa selepasnya boleh berfungsi, dan terowong tidak pernah bermula.
Nombor port tidak menamakan aplikasi
Port 53 membawa DNS secara konvensyen, dan pengendali OpenVPN juga boleh menerbitkan pendengar di situ, itulah sebabnya nombor ini pengenal yang lemah. Sesi OpenVPN pada UDP 53 masih sesi OpenVPN, dan pertanyaan DNS kepada pelayan pada port 53 tidak menyatakan apa-apa tentang sama ada terowong dibenarkan. Baris proto dan remote profil menentukan titik akhir luar; nombor port sendiri tidak menentukan apa-apa.
Itu memotong kedua-dua arah semasa mendiagnosis: kuar UDP generik ke port 53 membuktikan ada port yang menjawab, bukan bahawa perkhidmatan VPN yang menjawab. Uji dengan klien sebenar dan profil sebenar, kerana hanya itu melatih jabat tangan yang dijangka oleh perkhidmatan.
Buktikan pendengar sebelum menyalahkan rangkaian
Pada pelayan, sahkan apa yang terikat dengan ss -lunp | grep 53 dan bandingkan dengan protokol serta port profil. Dari rangkaian klien, jalankan klien dengan lebih terperinci supaya log menunjukkan alamat dan pengangkutan yang dicubanya. Jika pelayan mendengar dan paket klien tidak tiba, laluan atau dasar yang menolaknya, dan itu perbualan dengan pemilik rangkaian, bukan sebab untuk menukar port.
Port lain membantu hanya apabila perkhidmatan benar-benar mendengar di situ dan penggunaan membenarkannya. Memindahkan pendengar untuk mengelak penapisan rangkaian terurus ialah keputusan dasar, bukan langkah penyelesaian masalah. Tanya pemilik rangkaian apa yang dibenarkan sebelum menukar perkhidmatan, kerana jalan pintas yang melanggar dasar tetap akan ditutup kemudian. Catat jawapan itu di sebelah profil supaya orang seterusnya tidak mengulangi permintaan itu.
Periksa DNS selepas terowong, secara berasingan
Setelah terowong naik, periksa keadaan penyelesai pada antara muka VPN dan tanyakan satu nama dalaman dan satu nama awam. Jika nama dalaman gagal sementara terowong membawa trafik, tetapan DNS yang ditolak tidak digunakan, yang merupakan persoalan integrasi klien, bukan pengangkutan. Jika nama awam gagal dan nama dalaman berfungsi, dasar terowong berpecah melakukan apa yang dikonfigurasikan untuknya.
Serahkan perubahan DNS kepada pemilik penyelesai. Menulis ganti konfigurasi penyelesai terurus supaya satu ujian lulus boleh merosakkan nama peribadi untuk semua yang lain pada mesin. Jika terowong menolak penyelesai dan klien mengabaikannya, baiki integrasi klien dan bukannya menambah entri statik di tempat lain. Entri statik menyembunyikan kegagalan sehingga seseorang menukar rangkaian. Catat penyelesai mana yang dijangka menjawab setiap ruang nama.