Handshake WireGuard berhasil, layanannya tidak

Handshake selesai, klien menampilkan penghitung transfer terbaru, dan permintaan ke layanan di server yang sama tetap gagal. Kombinasi itu membingungkan orang karena terowongan jelas bekerja. Yang belum terbukti adalah pengiriman lokal: paket sudah mencapai host, dan host masih harus menerimanya pada soket yang tepat lalu meneruskannya ke proses yang berwenang menjawab. Periksa ketiga titik pemeriksaan itu secara berurutan.

Berhentilah pada yang pertama tidak terpenuhi, dan jangan menambahkan aturan untuk yang lain.

Handshake hanya membuktikan terowongan

Handshake WireGuard menetapkan kunci antar-peer dan mengizinkan lalu lintas untuk rentang yang didaftarkan setiap peer. Ia tidak mengatakan apa pun tentang proses mana yang mendengarkan di server, dan tidak pula apakah firewall host menerima paket yang dialamatkan ke salah satu alamatnya sendiri.

Perbedaan terakhir itulah yang paling sering terlewat: lalu lintas ke host itu sendiri adalah masukan lokal, sedangkan lalu lintas yang melewati host ke tempat lain adalah penerusan. Keduanya ditangani oleh rantai firewall dan pengaturan yang berbeda. Memeriksa rantai yang salah menghabiskan satu sore dan mengembalikan penghitung yang tampak tidak bersalah.

Baca pendengar dan rutenya

Di klien, pastikan alamat terowongan server dirutekan ke dalam terowongan. Di server, pastikan ada soket pada alamat yang digunakan klien, dan proses di belakangnya adalah yang Anda maksud.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Pendengar di 127.0.0.1 tidak akan pernah menjawab permintaan yang dialamatkan ke 10.66.0.1, apa pun yang diizinkan firewall. Pendengar di alamat umum akan menjawab, kecuali ada aturan yang memblokirnya. Daftar soket karena itu menyelesaikan separuh kasus sebelum aturan apa pun diperiksa. Port dan alamat bersama-sama menentukan apakah permintaan bisa mendarat.

Bandingkan alamat yang digunakan klien dengan alamat yang benar-benar dimiliki server pada antarmuka terowongan. Konfigurasi usang di salah satu sisi menghasilkan permintaan yang dirutekan dengan benar ke peer yang tidak memiliki alamat itu.

Terapkan aturan untuk masukan lokal, bukan penerusan

Jika paket tiba dan soket ada, batas yang tersisa adalah kebijakan masukan. Aturan yang mengizinkan penerusan tidak mengizinkan pengiriman lokal, dan aturan yang dibatasi pada satu antarmuka mungkin tidak cocok dengan nama antarmuka terowongan yang Anda harapkan.

Uji dengan satu port yang diizinkan ke layanan yang dimaksud alih-alih membuka host. Lalu periksa otorisasi aplikasi itu sendiri: daftar izin, persyaratan akun, atau pengikatan ke nama host tertentu dapat menolak permintaan yang sudah berhasil dikirim jaringan.

Biarkan pemeriksaan sertifikat tetap aktif. Identitas sertifikat yang tak terduga adalah informasi tentang host mana yang menjawab, bukan rintangan untuk dilewati. Mengklik lewat peringatan itu menyembunyikan satu-satunya petunjuk yang mengenali layanan yang salah.

Pisahkan kegagalan nama, ukuran, dan identitas

Layanan yang berfungsi berdasarkan alamat tetapi gagal berdasarkan nama adalah masalah DNS, dan perbaikannya ada pada konfigurasi resolver yang dikirim ke klien, bukan pada firewall. Layanan yang menjawab permintaan kecil tetapi macet pada respons lebih besar menunjuk ke ukuran paket dan MTU, yang merupakan penyelidikan sama sekali berbeda.

Galat HTTPS yang menyebut host salah biasanya berarti permintaan mencapai layanan lain, sering karena proksi atau pendengar lain memiliki port itu. Baca subjek sertifikat dan bandingkan dengan host yang ingin Anda capai. Perbandingan itu tidak memakan biaya dan sering mengakhiri penyelidikan.

Catat titik pemeriksaan mana yang gagal: soket, aturan masukan, atau kebijakan aplikasi. Satu baris itu membedakan gangguan jaringan dari keputusan otorisasi. Itu juga mencegah orang berikutnya membuka port yang tidak pernah menjadi masalah.