Port VPN diam? Listener, alamat bind, atau firewall host

VPN tidak menjawab apa pun di portnya, dan dua kemungkinan penyebabnya menuntut perbaikan yang berlawanan: entah tidak ada proses yang membuka socket, atau socket ada dan sesuatu di antara kedua mesin menghentikan paket. Satu perintah menuntaskan paruh pertama pertanyaan itu, karena itulah ia didahulukan sebelum aturan firewall disentuh. Urutan di bawah menghapus satu penjelasan per langkah alih-alih menambah dugaan lain. Menduga-duga di antara keduanya itulah yang mengubah diagnosis sepuluh menit menjadi satu malam penuh.

Anggap Anda bisa masuk ke server dan klien adalah profil sungguhan, bukan pemindai. Kedua anggapan itu penting, sebab probe umum tidak dapat menjawab pertanyaan yang khas protokol.

Apakah socket-nya ada sama sekali

Mulailah dari keterangan layanan tentang dirinya sendiri: apakah ia naik dan, lebih berguna, apa kesalahan pertamanya saat start. Kegagalan parsing, kunci yang hilang, atau kesalahan bind membuat listener tidak pernah terbentuk, dan proses dapat keluar begitu tenang sehingga baris status terbaca ambigu. Unit yang melaporkan aktif bukan bukti tersendiri, sebab proses utama bisa hidup sementara komponen yang seharusnya mengikat port sudah menyerah.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

Daftar socket adalah fakta yang menjadi landasan sisa diagnosis. Bacalah kolom alamat lokal, bukan hanya port, sebab di kolom itulah bind ke loopback dan bind ke antarmuka yang salah muncul. Listener yang ada di 127.0.0.1 berjalan sempurna dan tetap tak terlihat bagi laptop Anda.

Pada alamat dan keluarga mana socket menjawab

Dua kesalahan tampak sama dari sisi klien dan menjelaskan sebagian besar laporan "tidak terjangkau". Server yang terikat ke alamat loopback tidak pernah menerima lalu lintas dari mesin lain, dan server yang hanya terikat ke alamat IPv4 tidak pernah menjawab klien yang memanggil alamat IPv6 host yang sama. Bandingkan alamat di tabel socket dengan alamat yang benar-benar dipanggil klien, huruf demi huruf, sebelum menganggap apa pun tentang kebijakan.

Membatasi daftar ke satu port membuatnya tetap terbaca saat host menjalankan beberapa layanan. Filter sport mengambil port bersama transport yang Anda uji:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

Kolom protokol mengubah seluruh jawaban

Tabel socket berkunci pada protokol sekaligus port, dan keduanya entri yang mandiri. Layanan yang menjawab TCP pada 1194 tidak memberi tahu apa pun tentang apakah ada yang mendengarkan di UDP 1194, dan klien hanya akan memakai salah satunya. Pastikan transport mana yang dipilih konfigurasi server dan mana yang dikirim profil klien, lalu cari baris yang tepat itu.

UDP punya lipatan kedua: probe tanpa autentikasi bukan kesalahan yang wajib dijawab layanan. Pemindaian yang melaporkan port sebagai diam telah mengukur kehati-hatian layanan, bukan ketersediaannya, jadi ujilah dengan klien dan profil sungguhan.

Satu percobaan, tiga tempat menengok

Dari klien yang disetujui lakukan tepat satu percobaan dan catat waktunya sampai detik. Lalu baca tiga sumber untuk jendela itu: aturan jaringan atau konsol penyedia, penghitung atau log firewall host, dan log layanan itu sendiri. Melakukannya sekali inilah yang membuat ketiga keterangan dapat dibandingkan, dan biayanya lebih murah daripada mengulang percobaan yang stempel waktunya tak dicatat siapa pun.

Kedua hasil menunjuk arah berlawanan. Bila tidak ada paket yang sampai ke host, jalur menjatuhkannya dan listener tidak relevan. Bila paket sampai ke socket dan layanan menolaknya, jalur baik-baik saja dan jawabannya ada pada protokol, kriptografi, atau kredensial. Membuka port bagi layanan yang sudah menerima koneksi membuat diagnosis berikutnya lebih sulit, bukan lebih mudah.

Namai tahapannya sebelum mengubah aturan

Negosiasi yang mulai dan autentikasi yang gagal adalah satu kegagalan, dan terowongan yang terbentuk sementara penerusan macet adalah kegagalan yang sama sekali lain. Menamai tahap lebih dulu menjaga perbaikan tetap sempit: masalah kredensial tidak diperbaiki aturan firewall, dan masalah jalur data tidak diperbaiki restart.

Pakailah diagnosis tersempit yang menjawab pertanyaan. Pengamatan paket sementara pada satu port, di bawah kendali administrator, adalah alat yang wajar; menonaktifkan seluruh firewall bukan, karena hasilnya menjadi mustahil diatribusikan. Dokumentasi ss mencakup filter yang dipakai di atas, dan itu langkah pertama yang lebih murah daripada tangkapan apa pun. Catat cabang mana yang Anda buktikan, dan kejadian berikutnya mulai dari jawaban yang sudah diketahui.