ufw allow 443 tidak melakukan apa pun untuk layanan di balik VPN

Ping berhasil dari klien VPN, layanan TCP kehabisan waktu, dan ufw allow 443/tcp tidak mengubah apa pun. Ketika aplikasi berjalan di host di balik gateway dan bukan pada gateway itu sendiri, izin tersebut ditulis untuk jalur lalu lintas yang salah. Paket tidak dialamatkan ke firewall dan tidak dikirim ke proses lokal, sehingga aturan masuk tidak pernah melihatnya. Perbaikannya adalah aturan rute yang menyasar aliran yang diteruskan, dan buktinya sudah ada di log.

Tentukan apakah tujuan bersifat lokal atau diteruskan

Baca paket sebagaimana kernel melihatnya. Lalu lintas yang dikirim ke layanan di gateway adalah masukan lokal. Lalu lintas yang diteruskan gateway ke host lain bersifat diteruskan, dan UFW menyimpan kumpulan aturan terpisah untuk kedua jalur. Perbedaannya ditentukan oleh alamat tujuan dan pencarian rute, bukan oleh antarmuka tempat paket tiba.

Baris log yang menunjukkan antarmuka sama di kedua bidang IN dan OUT tetap dapat menggambarkan paket yang dirutekan, karena terowongan yang membawa klien masuk dan keluar dari satu perangkat tampak persis seperti itu. Alamat tujuan menjawab pertanyaan itu lebih cepat daripada nama antarmuka. Melihat nama yang sama dua kali tidak membuktikan pengiriman lokal, dan mengarang antarmuka terowongan yang tidak pernah dibuat penerapan juga tidak membantu.

Baca blok itu sebelum menambahkan aturan apa pun

Reproduksi satu upaya koneksi yang diizinkan dan catat sumber, tujuan, protokol, serta port tujuannya seperti yang dicatat gateway. Bandingkan keempat nilai itu dengan entri log dan dengan lokasi sebenarnya layanan. Ping yang berhasil sebelumnya hanya membuktikan bahwa pertukarannya sendiri diizinkan, dan firewall dapat memperlakukan TCP SYN ke sebuah aplikasi dengan cara yang sangat berbeda.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

Perintah pertama mengembalikan putusan beserta bidangnya, dan yang kedua menunjukkan apa yang sudah dimuat dan dalam urutan apa. Baca keduanya sebelum menyunting apa pun, karena penolakan sebelumnya di atas aturan Anda menjelaskan gejala yang sama tanpa aturan yang hilang.

Tulis aturan rute tersempit yang sesuai

Dalam contoh ini klien datang pada tun0 dari 172.20.8.0/24, layanan mendengarkan pada 10.30.0.15 di port 8443, dan gateway keluar melalui ens5. Nilai-nilai itu dipilih agar tidak menyerupai default VPC cloud 10.0.0.0/16 atau jaringan rumah 192.168.0.0/16, dan 8443 menjauhkan contoh dari pendengar 443 milik gateway sendiri.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

Uji jalan mencetak kumpulan aturan yang akan dihasilkan, dan itu cara termurah untuk melihat apakah aturan Anda jatuh sebelum atau sesudah penolakan yang sudah ada. Pastikan nama antarmuka dan alamat dalam terhadap penerapan, bukan terhadap contoh, dan ingat bahwa ketika NAT tujuan berjalan lebih dulu, filter melihat tujuan yang telah diterjemahkan.

Pertahankan jalur balik yang stateful

UFW melacak koneksi yang diizinkan, sehingga balasan untuk aliran diteruskan yang diizinkan diterima tanpa aturan balik eksplisit. Menambahkan aturan tanpa batas ke arah sebaliknya agar semuanya berjalan memperlebar kebijakan jauh melampaui satu layanan dan tidak diperlukan untuk pertukaran permintaan-jawaban biasa. Pertahankan jalur balik tetap implisit dan kumpulan aturan tetap terbaca.

Terapkan aturan hanya setelah uji jalan sesuai dengan maksud Anda, lalu pastikan daftar terurut menampilkannya pada posisi yang diharapkan. Pertahankan pendengar VPN dan aturan manajemen sebagai hal terpisah, karena mengubahnya adalah keputusan berbeda dari mengizinkan satu aplikasi. Catat perubahan di tempat yang sama dengan tempat topologi ditulis, agar insinyur berikutnya tidak perlu menemukannya lagi dari tangkapan paket.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Periksa apa yang tidak dapat UFW paksakan untuk Anda

Aturan yang benar tetap membutuhkan penerusan kernel dan rute yang mencapai layanan. Pastikan keduanya sebelum menyalahkan firewall untuk kedua kalinya.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Kemudian lihat ke luar host. Pada instans cloud, kebijakan UFW tamu tidak menggantikan grup keamanan, ACL subnet, atau konfigurasi penerusan penyedia itu sendiri, jadi pemblokiran lokal adalah bukti tentang satu lapisan dan bukan bukti bahwa setiap lapisan lain mengizinkan layanan.

Akhiri dengan menguji koneksi baru saat firewall aktif, dari sumber yang diizinkan dan dari sumber yang tidak terkait. Menonaktifkan UFW menghapus gejala dan menghancurkan bukti dalam perintah yang sama, karena itu seharusnya menjadi eksperimen terakhir, bukan yang pertama.