VPN UDP diam saat pemindaian port? Mengapa itu terjadi
WireGuard dan OpenVPN yang diperketat membuang datagram yang gagal autentikasi tanpa membalas. Diamnya pemindai adalah perilaku yang wajar, bukan port tertutup.
Anda memindai port VPN, tidak mendapat balasan, lalu menyimpulkan bahwa layanan mati atau firewall tertutup. Pada WireGuard, dan pada kanal kontrol OpenVPN yang membawa autentikasinya sendiri, kesimpulan itu tidak berlaku. Datagram tanpa materi autentikasi yang sah dibuang tanpa balasan, jadi diam adalah tampilan layanan yang sehat dari luar. Uji itu salah sebelum terowongannya salah.
Diam adalah protokolnya, bukan gangguan
UDP tidak memiliki penyiapan koneksi, jadi tidak ada SYN dan tidak ada pengakuan yang memungkinkan pemindai membedakan port terbuka dari port tersaring. Probe datang sebagai datagram terpisah, dan layanan memeriksa apakah datagram itu cocok dengan protokol yang diharapkannya. Bila tidak cocok, paket dibuang, dan pembuangan adalah perilaku yang terdokumentasi, bukan kerusakan.
WireGuard memvalidasi pesan handshake-nya secara kriptografis dan mengabaikan apa pun yang gagal. OpenVPN dengan tls-auth atau tls-crypt melakukan hal yang sama untuk kanal kontrolnya. Pada kedua kasus, muatan sembarang tidak pernah mencapai tahap yang menghadap pengguna, jadi tidak ada yang bisa dibalas dan tidak ada galat yang bisa dikembalikan.
TCP akan memberi Anda reset dari port tertutup. UDP membuat Anda berada dalam ketidakpastian, yang diselesaikan pemindai dengan mencetak terbuka atau tersaring alih-alih menebak.
Apa yang bisa dan tidak bisa disimpulkan pemindai
Hasil pemindaian hanya seinformatif muatan yang dikirimnya. Urutkan kemungkinan pengamatan menurut apa yang sebenarnya didukung masing-masing:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
Bacalah baris ketiga sebagai satu-satunya uji positif dalam daftar. Uji itu memerlukan profil asli, kunci asli, dan titik akhir yang tepat, dan itulah yang tidak dimiliki pemindai generik.
Lihat kedua ujung jalur
Untuk server yang Anda kelola, tangkap paket di antarmuka sebelum menarik kesimpulan apa pun, lalu tanyakan kepada layanan apa yang dilihatnya. Kedua perintah memerlukan root di gateway:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showJika tidak ada paket yang muncul di antarmuka, jalur membuangnya sebelum layanan melihat apa pun, dan perhentian berikutnya adalah perutean dan penyaringan. Jika paket tiba tetapi tidak ada handshake yang selesai, layanan dapat dijangkau dan ketidakcocokannya ada pada kunci, konfigurasi titik akhir, atau versi protokol. Perbandingan itu menjawab pertanyaan yang tidak dapat dijawab pemindai. Jalankan saat klien nyata mencoba terhubung, bukan saat pemindai mengulang dirinya.
Ubahlah ujinya, bukan perlindungannya
Jalan pintas yang menggoda adalah menonaktifkan perlindungan kanal kontrol agar diagnostik mendapat balasan. Itu menukar properti keamanan yang nyata dengan hasil pemindaian yang lebih indah, dan itu arah yang salah. Gunakan profil yang sah dari jaringan yang disetujui, dan catat titik akhir serta waktunya agar perbandingan dapat diulang.
Uji yang paling berguna adalah uji diferensial: profil yang sama pada jalur yang berfungsi dan pada jalur yang tidak. Jika jalur yang berfungsi menghasilkan handshake dan jalur yang gagal tidak menghasilkan apa pun di antarmuka, Anda telah menemukan letak putusnya tanpa melemahkan apa pun.
Jadi paket UDP yang tidak dijawab tidak membuktikan bahwa server sedang luring maupun bahwa server itu aman. Itu membuktikan bahwa probe ini, pada jalur ini, pada saat ini, tidak diterima.