VPN tersambung tetapi firewall tetap memblokir: cara tahu yang mana

Tunelnya aktif dan satu port masih gagal. Baca jalurnya, lalu kebijakan di setiap lapisan, dan ubah aturan tersempit alih-alih mematikan salah satu dari dua kendali.

Klien bilang tersambung, sumber daya masih menolak, dan langkah berikutnya yang biasa adalah mematikan sesuatu. Kedua kendali dalam kalimat itu melakukan pekerjaan berbeda: VPN membangun jalur untuk lalu lintas yang tercakup, dan firewall memutuskan per koneksi apakah lalu lintas boleh lewat. Tunel yang berfungsi dengan kebijakan yang menolak terlihat persis seperti tunel rusak dari kursi pengguna, jadi tugasnya adalah mencari tahu lapisan mana yang menjawab. Inilah urutan yang saya ikuti, dengan pembacaan yang memberi tahu Anda untuk berhenti.

Pisahkan jalur dari kebijakan

Mulailah dari bentuk kegagalan, karena itu informasi gratis. Paket yang dijatuhkan menghasilkan batas waktu: klien mencoba lagi, tidak ada yang kembali, dan perintah menggantung sampai menyerah. Penolakan menghasilkan penolakan atau reset: sesuatu menjawab dan berkata tidak. Layanan yang tidak mendengarkan menolak pada host itu sendiri, tanpa firewall sama sekali.

Ketiga hasil itu menunjuk ke lapisan berbeda. Batas waktu berarti ada kebijakan di suatu tempat yang membuang diam-diam, atau jalur tidak pernah meninggalkan mesin. Ditolak berarti Anda mencapai host dan tumpukannya atau firewall host-nya menolak. Sunyi total, dengan antarmuka tunel aktif dan tidak ada rute ke tujuan, berarti jalurnya salah dan tidak ada aturan firewall yang akan memperbaikinya.

Baca jalur dalam satu lintasan

Pastikan tunel mencakup tujuan sebelum melihat satu aturan pun. Tunel terpisah yang hanya membawa subnet kantor tidak akan merutekan permintaan ke rentang lain, dan kegagalan lalu tampak seperti blokir firewall yang bukan:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Keluaran rute menyebut antarmuka tempat paket akan keluar dan alamat sumber yang akan dibawanya. Jika antarmuka itu kartu jaringan fisik Anda dan bukan tunel, masalahnya ada pada perutean atau pada rentang yang diizinkan tunel, dan itu milik konfigurasi VPN, bukan firewall.

Satu jebakan khusus VPN layak diperiksa sendiri. Di WireGuard, AllowedIPs sebuah peer adalah rute sekaligus penyaring kriptografis: paket yang alamat sumbernya tidak cocok dengan himpunan yang diizinkan peer dijatuhkan sebelum aturan firewall mana pun diperiksa. Jadi firewall host yang sepenuhnya benar bisa berada di balik penjatuhan senyap yang tampak seperti kebijakan, dan perbaikannya adalah satu baris konfigurasi kunci, bukan aturan.

Baca kebijakan pada lapisan yang menjawab

Setelah jalurnya benar, telusuri kebijakan dari host ke luar dan perhatikan satu lapisan yang penghitungnya bergerak:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Soket yang mendengarkan menjawab pertanyaan berbeda dari aturan. Jika tidak ada yang mendengarkan di port, kernel menolak koneksi dan tidak ada aturan masuk yang relevan. Jika soket ada dan koneksi dari klien jarak jauh kedaluwarsa, penjatuhan terjadi di suatu tempat di jalur, dan penghitung aturan memberi tahu apakah itu terjadi di sini.

Nyalakan pencatatan untuk profil atau rantai yang Anda curigai alih-alih menebak dari luar. Satu penjatuhan tercatat yang menyebut sumber, tujuan, dan port mengidentifikasi lapisan dan aturannya, dan itu juga membuktikan paket tiba, yang tidak dapat dipastikan oleh pengujian sisi klien mana pun.

Baca keputusan gateway saat tunel berakhir di sana

Pada gateway situs-ke-situs atau akses jarak jauh, VPN mengautentikasi pengguna dan kebijakan mengotorisasi sumber daya, dan itu pemberian yang terpisah. Pengguna yang diizinkan masuk tunel tidak otomatis diizinkan ke setiap host internal, dan penolakan sering datang dari aturan penerusan sementara tunelnya sendiri sehat. Pemisahan yang sama muncul di IPsec, tempat kebijakan keamanan yang memilih lalu lintas berbeda dari penyaring yang mengizinkannya, dan karena itulah keduanya didokumentasikan sebagai mekanisme berbeda di RFC 4301.

Periksa jalur balik dengan hati-hati seperti jalur keluar. Penyaringan stateful perlu melihat balasannya, jadi perutean asimetris melalui tunel ke satu arah dan mengelilinginya ke arah lain menghasilkan penjatuhan yang tampak acak dan hanya terulang dari sebagian klien. Jika lalu lintas mencapai gateway dan berhenti, baca aturan penerusan dan rute balik bersama-sama sebelum memperluas apa pun.

Gateway juga tempat aturan NAT atau penyamaran dapat menyembunyikan sumber sebenarnya. Jika host internal melihat alamat gateway alih-alih klien, aturan firewall host mereka yang seharusnya cocok dengan kumpulan klien tidak akan pernah cocok, dan perbaikannya ada di gateway, bukan di setiap server.

Ubah lapisan tersempit, lalu verifikasi

Tahan diri dari perbaikan luas. Mematikan firewall host, menambahkan aturan yang mengizinkan semua, atau memaksa setiap antarmuka ke profil tepercaya masing-masing menghapus kendali yang sedang menjalankan tugasnya, dan perubahannya bertahan setelah insiden. Aturan yang dibatasi pada rentang sumber dan port yang bersangkutan lebih mudah ditinjau, lebih mudah dihapus, dan membiarkan sisa kebijakan mesin utuh.

Verifikasi dengan pengujian yang sama yang gagal, dari klien yang sama, lalu sekali lagi setelah menyambung ulang, karena aturan yang cocok sebelum tunel bernegosiasi ulang bisa berhenti cocok sesudahnya:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Sebelum menutupnya:

  • Rute ke tujuan keluar melalui antarmuka tunel, dan alamat sumber cocok dengan yang diharapkan kebijakan.
  • Ada yang mendengarkan di port, dan penolakan atau batas waktu dikaitkan dengan aturan bernama, bukan diasumsikan.
  • Gateway meneruskan ke kedua arah, dan tujuan melihat sumber yang menjadi dasar aturan Anda ditulis.
  • Tidak ada kendali yang dimatikan agar pengujian lolos, dan perubahan yang Anda buat menyebut satu rentang sumber dan satu port.

Artikel terkait