ufw allow 443 tidak membantu perkhidmatan di belakang VPN

Ping berjaya dari klien VPN, perkhidmatan TCP tamat masa, dan ufw allow 443/tcp tidak mengubah apa-apa. Apabila aplikasi berjalan pada hos di belakang get laluan dan bukan pada get laluan itu sendiri, kebenaran itu ditulis untuk laluan trafik yang salah. Paket tidak dialamatkan kepada tembok api dan tidak dihantar kepada proses tempatan, jadi peraturan input tidak pernah melihatnya. Pembaikan ialah peraturan laluan yang menyasarkan aliran yang dimajukan, dan buktinya sudah ada dalam log.

Tentukan sama ada destinasi itu tempatan atau dimajukan

Baca paket seperti yang dilihat oleh kernel. Trafik yang dihantar kepada perkhidmatan pada get laluan ialah input tempatan. Trafik yang get laluan majukan ke hos lain ialah dimajukan, dan UFW menyimpan set peraturan berasingan untuk kedua-dua laluan. Perbezaan itu ditentukan oleh alamat destinasi dan carian laluan, bukan oleh antara muka tempat paket tiba.

Baris log yang menunjukkan antara muka yang sama dalam kedua-dua medan IN dan OUT masih boleh menerangkan paket yang dilalukan, kerana terowong yang membawa klien masuk dan keluar dari satu peranti kelihatan tepat seperti itu. Alamat destinasi menyelesaikan soalan itu lebih cepat daripada nama antara muka. Melihat nama yang sama dua kali tidak membuktikan penghantaran tempatan, dan mencipta antara muka terowong yang tidak pernah dibuat oleh penggunaan juga tidak membantu.

Baca blok itu sebelum menambah apa-apa peraturan

Hasilkan semula satu percubaan sambungan yang dibenarkan dan rakam sumber, destinasi, protokol serta port destinasinya seperti yang direkodkan oleh get laluan. Bandingkan keempat-empat nilai itu dengan entri log dan dengan lokasi sebenar perkhidmatan. Ping yang berjaya sebelum ini hanya membuktikan pertukarannya sendiri dibenarkan, dan tembok api mungkin mengendalikan TCP SYN ke aplikasi dengan cara yang sangat berbeza.

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

Perintah pertama mengembalikan keputusan bersama medannya, dan yang kedua menunjukkan apa yang sudah dimuatkan dan dalam susunan apa. Baca kedua-duanya sebelum menyunting apa-apa, kerana penafian terdahulu di atas peraturan anda menerangkan simptom yang sama tanpa sebarang peraturan yang hilang.

Tulis peraturan laluan tersempit yang sesuai

Dalam contoh ini klien tiba pada tun0 dari 172.20.8.0/24, perkhidmatan mendengar pada 10.30.0.15 di port 8443, dan get laluan keluar melalui ens5. Nilai-nilai itu dipilih supaya tidak menyerupai lalai VPC awan 10.0.0.0/16 atau rangkaian rumah 192.168.0.0/16, dan 8443 menjauhkan contoh daripada pendengar 443 get laluan itu 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

Larian kering mencetak set peraturan yang akan terhasil, dan itulah cara termurah untuk melihat sama ada peraturan anda jatuh sebelum atau selepas penafian sedia ada. Sahkan nama antara muka dan alamat dalaman terhadap penggunaan dan bukan terhadap contoh, dan ingat bahawa apabila NAT destinasi berjalan dahulu, penapis melihat destinasi yang telah diterjemah.

Kekalkan laluan balik sebagai stateful

UFW menjejaki sambungan yang dibenarkan, jadi balasan kepada aliran dimajukan yang dibenarkan diterima tanpa peraturan terbalik yang jelas. Menambah peraturan tanpa had dalam arah bertentangan supaya semuanya berfungsi meluaskan dasar jauh melebihi satu perkhidmatan dan tidak diperlukan untuk pertukaran permintaan-jawapan biasa. Kekalkan laluan balik secara tersirat dan set peraturan kekal boleh dibaca.

Guna peraturan itu hanya selepas larian kering sepadan dengan niat anda, kemudian sahkan senarai tersusun menunjukkannya pada kedudukan yang dijangka. Kekalkan pendengar VPN dan peraturan pengurusan sebagai perkara berasingan, kerana mengubahnya ialah keputusan berbeza daripada membenarkan satu aplikasi. Catat perubahan di tempat topologi ditulis, supaya jurutera seterusnya tidak perlu menemuinya semula daripada 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 UFW tidak boleh kuatkuasakan untuk anda

Peraturan yang betul masih memerlukan pemajuan kernel dan laluan yang sampai ke perkhidmatan. Sahkan kedua-duanya sebelum menyalahkan tembok api kali kedua.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Kemudian lihat di luar hos. Pada instans awan, dasar UFW tetamu tidak menggantikan kumpulan keselamatan, ACL subnet atau konfigurasi pemajuan penyedia itu sendiri, jadi penyekatan tempatan ialah bukti tentang satu lapisan dan bukan bukti bahawa setiap lapisan lain membenarkan perkhidmatan.

Akhiri dengan menguji sambungan baharu semasa tembok api diaktifkan, dari sumber yang dibenarkan dan dari sumber yang tidak berkaitan. Melumpuhkan UFW menghapuskan simptom dan memusnahkan bukti dalam perintah yang sama, kerana itu ia patut menjadi eksperimen terakhir dan bukan yang pertama.