Aturan forward semua port bisa menelan listener WireGuard Anda

Sebuah gateway publik sudah menjalankan WireGuard pada UDP 51820, SSH pada 22, dan satu aplikasi yang harus dapat dijangkau dari internet. Aturan yang menggiurkan meneruskan setiap port ke peer dan menyatakan pekerjaan selesai. Pada gateway WireGuard, aturan itu dapat menangkap transport tunnel itu sendiri dan mengunci Anda dari mesin yang menjadi titik akhir tunnel. Publikasi adalah keputusan routing dengan pengecualian bidang kendali, bukan satu baris DNAT.

Pintu masuk publik atau pintu masuk tunnel: pilih satu

Menerbitkan layanan menciptakan titik masuk baru di internet. Itu tidak sama dengan memberikan keanggotaan VPN kepada peer, karena pengunjung tidak pernah masuk ke tunnel dan gateway menjadi wajah publik backend. Perbedaan itulah yang menentukan audiens aturan dan sertifikatnya.

Antarmuka administratif jarang pantas berada di posisi itu. Halaman admin yang dicapai klien VPN berwenang menjaga permukaan serangan di dalam tunnel dan menghindari mengekspos formulir login ke pemindaian sembarangan. Endpoint aplikasi publik tetap memerlukan sertifikat TLS sendiri, autentikasi, dan pembatasan laju; lompatan WireGuard yang terenkripsi tidak melindungi bagian pengunjung sampai ke gateway.

Jika layanan memang harus publik, catat nama host, sertifikat yang mencakupnya, dan rentang pengunjung yang semestinya mencapainya. Ketiga fakta itu nanti menentukan bentuk aturan dan kebijakan filter. Apa pun di luarnya adalah perluasan cakupan pada listener publik.

Satu port masuk, satu backend keluar

Gunakan satu port publik dan satu layanan backend. Dalam contoh ini eth0 membawa alamat publik 198.51.100.20, alamat tunnel gateway adalah 10.200.0.1, dan peer menjalankan aplikasi pada 10.200.0.7. TCP publik 9443 dipetakan ke TCP 8443 milik peer:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

Aturan SNAT cocok dengan backend yang telah diterjemahkan dan tujuan publik asli, sehingga koneksi lain ke layanan backend yang sama tetap di luar pemetaan ini. Aturan itu juga menyembunyikan alamat pengunjung dari peer, dan itulah kompromi yang menjadikan jalur balik yang dirutekan dengan mempertahankan sumber sebagai desain tersendiri. Referensi ekstensi iptables mendokumentasikan kedua target dan opsi pencocokannya.

Forwarding tetap harus diaktifkan, dan rantai filter memerlukan izin untuk tujuan dan port yang diterjemahkan plus balasan yang sudah terjalin. Rantai FORWARD melihat tujuan yang diterjemahkan setelah DNAT, jadi aturan yang ditulis terhadap alamat publik tidak cocok dengan paket yang diteruskan. Tulis izinnya terhadap tuple backend, bukan tuple publik.

Peer harus menerima koneksi layanan dari alamat tunnel gateway dan mengirim balasannya kembali melalui tunnel. AllowedIPs-nya harus mengizinkan sumber yang benar-benar diterimanya, yang di bawah penerjemahan sumber adalah alamat tunnel gateway, dan entri 0.0.0.0/0 yang luas pada setiap peer tidak diperlukan untuk desain ini. Yang menjatuhkan lalu lintas balik adalah peer yang daftarnya menghilangkan alamat itu, atau desain yang mempertahankan sumber dan justru meneruskan alamat pengunjung, jadi periksa sumber yang benar-benar dilihat peer, bukan yang ada di aturan Anda.

Jauhkan listener gateway sendiri dari aturan

Ganti pencocokan port dengan aturan yang mencakup setiap tujuan TCP dan UDP, dan socket WireGuard milik gateway sendiri masuk ke dalamnya. Penerjemahan tujuan terjadi sebelum mesin memutuskan bahwa sebuah paket bersifat lokal, sehingga UDP 51820 bisa berakhir di peer alih-alih di proses yang memegang setiap koneksi peer. Aturan termuat dengan sukses dan tunnel mati, kegagalan yang sulit dibaca dari sisi peer.

SSH, agen pemantauan, dan layanan lain yang dihosting di gateway memiliki paparan yang sama. Aturan yang meneruskan semuanya tidak membedakan bidang kendali dari aplikasi yang dipublikasikan, dan reboot pertama setelah perubahan adalah saat penguncian menjadi jelas. Aturan yang menangkap semua tidak memperingatkan tentang layanan yang diam-diam diambil alihnya. Anda menemukannya saat koneksi berikutnya gagal.

Jika forwarding luas memang diperlukan, pesan port kendali sebelum aturan yang menangkap semua atau gunakan alamat publik terpisah untuk publikasi. Opsi kedua lebih bersih karena alamat kendali mempertahankan kebijakannya sendiri, tetapi penyedia harus menyediakan alamat itu; menambahkan catatan DNS tidak mengalokasikan satu.

Forwarding TCP dan UDP yang luas juga bukan semua protokol. ICMP, IPv6, umpan balik path-MTU, dan transport VPN luar memerlukan kebijakan sendiri, dan aturan yang mencakup TCP dan UDP menyerahkan kasus itu ke rantai default.

Pilih model sebelum menulis aturan

Empat bentuk mencakup sebagian besar publikasi gateway, dan pilihannya bergantung pada berapa banyak layanan yang Anda jalankan dan berapa besar risiko bidang kendali yang dapat Anda tanggung. Tabel di bawah mengurutkannya dari yang tersempit ke yang terluas.

Mulailah dengan model sempit meskipun Anda memperkirakan lebih banyak layanan nanti. Model itu paling mudah diaudit, dan mengubah sekumpulan aturan sempit menjadi aturan tangkap-semua yang telah ditinjau lebih sederhana daripada menemukan listener mana yang ditangkap aturan luas. Model mana pun yang Anda pilih, simpan aturannya pada pemilik firewall. Menerapkan baris iptables di samping konfigurasi UFW atau nftables yang juga mengelola rantai yang sama menghasilkan kebijakan yang berubah tergantung urutan boot.

Buktikan publikasi dan jalur kendali

Uji dari klien luar yang berwenang memakai nama host yang disetujui dan sertifikat yang valid untuknya. Pastikan backend mana yang menjawab, lalu periksa bahwa port publik yang tidak terkait tetap ditolak. Pemeriksaan sertifikat yang dinonaktifkan bukan uji HTTPS yang lulus, dan koneksi yang mencapai backend yang salah lebih buruk daripada yang gagal.

Setelah itu verifikasi gateway itu sendiri: sambungkan peer WireGuard, buka sesi SSH, dan pastikan pemantauan masih melapor. Layanan yang dipublikasikan bisa bekerja sementara bidang kendali rusak, jadi kedua pemeriksaan termasuk dalam jendela perubahan yang sama. Reboot sekali untuk membuktikan aturan diterapkan ulang dalam urutan yang diharapkan, lalu hapus publikasi dan pastikan penghapusannya benar-benar cocok dengan penambahannya. Kumpulan besar penambahan saat start dengan pembersihan yang tidak lengkap adalah cara uji sementara menjadi celah permanen.