OpenVPN di port 53: tiga percakapan yang sering dikacaukan
Pencarian endpoint, transport terenkripsi, dan DNS setelah tunnel adalah tiga percakapan. Tentukan tahap mana yang gagal sebelum mengganti port atau resolver.
Laporan yang menyebut VPN terblokir di port 53 mencampur tiga pengamatan yang gagal karena alasan berbeda. Penyelesaian nama endpoint terjadi sebelum ada tunnel, transport terenkripsi adalah percakapan terpisah, dan kueri DNS yang dilakukan sesudahnya adalah yang ketiga. Masing-masing punya tanda kegagalannya sendiri, dan hanya satu di antaranya yang benar-benar soal DNS.
Kelompokkan paket berdasarkan tujuannya sebelum mengubah apa pun, karena perbaikan mengikuti tahapnya.
Tiga percakapan, satu nomor port
Percakapan pertama adalah pencarian nama untuk endpoint: mesin Anda bertanya kepada resolver yang dikonfigurasi di mana vpn.example.com berada, dan jawaban itu datang lewat DNS biasa sebelum klien mengirim satu paket tunnel pun. Yang kedua adalah transport OpenVPN itu sendiri, yang terhubung ke alamat hasil pencarian pada protokol dan port yang disebut profil. Yang ketiga terjadi setelah tunnel aktif, ketika aplikasi meminta nama dan setelan resolver yang didorong menentukan siapa yang menjawab.
Ketiganya bisa berhasil atau gagal secara terpisah. Klien bisa menyelesaikan endpoint-nya dengan sempurna tetapi tetap gagal menjangkau listener, dan bisa membangun tunnel sementara setiap pencarian nama internal gagal karena setelan 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 tabel itu sebagai daftar periksa, bukan sebagai deskripsi. Jika nama endpoint tidak terselesaikan, tidak ada yang bisa berjalan sesudahnya, dan tunnel tidak pernah dimulai.
Nomor port tidak menamai aplikasinya
Port 53 membawa DNS berdasarkan konvensi, dan operator OpenVPN juga bisa menerbitkan listener di sana, itulah sebabnya nomor ini menjadi pengenal yang buruk. Sesi OpenVPN di UDP 53 tetap sesi OpenVPN, dan kueri DNS ke server di port 53 tidak mengatakan apa pun tentang apakah tunnel diizinkan. Baris proto dan remote pada profil menentukan endpoint luar; nomor port tidak menentukan apa pun dengan sendirinya.
Itu memotong dua arah saat mendiagnosis: probe UDP generik ke port 53 membuktikan ada port yang menjawab, bukan bahwa layanan VPN yang menjawab. Uji dengan klien asli dan profil asli, karena hanya itu yang menjalankan handshake yang diharapkan layanan.
Buktikan listener sebelum menyalahkan jaringan
Di server, pastikan apa yang terikat dengan ss -lunp | grep 53 dan bandingkan dengan protokol serta port pada profil. Dari jaringan klien, jalankan klien dengan verbositas lebih tinggi agar log menunjukkan alamat dan transport yang dicobanya. Jika server mendengarkan dan paket klien tidak tiba, jalur atau kebijakan yang menolaknya, dan itu percakapan dengan pemilik jaringan, bukan alasan mengganti port.
Port lain hanya membantu bila layanan benar-benar mendengarkan di sana dan penerapannya mengizinkan. Memindahkan listener untuk menghindari penyaringan jaringan terkelola adalah keputusan kebijakan, bukan langkah pemecahan masalah. Tanyakan kepada pemilik jaringan apa yang diizinkan sebelum mengubah layanan, karena jalan pintas yang melanggar kebijakan tetap akan ditutup nanti. Catat jawaban itu di samping profil agar orang berikutnya tidak mengulang permintaan.
Periksa DNS setelah tunnel, secara terpisah
Setelah tunnel aktif, periksa status resolver pada antarmuka VPN dan kuerikan satu nama internal dan satu nama publik. Jika nama internal gagal sementara tunnel membawa lalu lintas, setelan DNS yang didorong tidak diterapkan, yang merupakan pertanyaan integrasi klien, bukan transport. Jika nama publik gagal dan nama internal berhasil, kebijakan split tunnel melakukan apa yang dikonfigurasi untuk dilakukannya.
Serahkan perubahan DNS kepada pemilik resolver. Menimpa konfigurasi resolver terkelola agar satu pengujian lolos bisa merusak nama privat untuk semua hal lain di mesin. Jika tunnel mendorong resolver dan klien mengabaikannya, perbaiki integrasi klien alih-alih menambahkan entri statis di tempat lain. Entri statis menyembunyikan kegagalan sampai seseorang berpindah jaringan. Tuliskan resolver mana yang diharapkan menjawab setiap namespace.