Firewall VPS: buka hanya port VPN, kemudian buktikannya

Firewall yang hanya membenarkan port VPN bukan satu peraturan. Ia tiga keputusan berasingan yang kebetulan melibatkan nombor port yang sama: rantaian input menentukan apa yang boleh sampai ke proses setempat, rantaian pemajuan menentukan apa yang boleh melalui hos bagi pihak klien terowong, dan jadual NAT menulis semula alamat sumber semasa keluar. Salah satu daripadanya dan hasilnya jarang menjadi gangguan yang bersih. Anda mendapat hos yang menerima klien tetapi tidak memuatkan apa-apa, atau hos yang kelihatan tertutup sehingga seseorang membaca susunan rantaian.

Satu-satunya port yang tidak boleh ditutup

Pendengar VPN mesti menerima sambungan daripada alamat yang tidak dapat anda ramalkan, jadi ia perkhidmatan awam mengikut takrifan. Inilah satu-satunya pengecualian yang menjadi asas reka bentuk: satu port UDP untuk OpenVPN, satu port UDP untuk WireGuard, satu port TCP untuk VPN SSL. Segala yang lain terletak di belakang terowong, bermakna perkhidmatan aplikasi harus mengikat pada alamat terowong atau loopback, bukan pada setiap antara muka.

Mengikat bagaimanapun bukan penguatkuasaan. Proses yang terikat pada 0.0.0.0 hanya boleh dicapai jika peraturan membenarkannya, dan dasar lalai ialah sandaran bagi trafik yang tidak sepadan dengan mana-mana peraturan, bukan peraturan yang mengawal port. Penerimaan yang diletakkan di atas penolakan anda tetap penerimaan, dan memindahkan perkhidmatan keluar dari alamat awam ialah penambahbaikan berasingan, bukan pengganti rantaian.

Input, pemajuan dan NAT menjawab soalan berbeza

Trafik input ditujukan kepada hos itu sendiri, jadi di situlah pendengar VPN dan laluan pentadbiran berada. Trafik pemajuan melalui hos, dan klien terowong memerlukannya bersama net.ipv4.ip_forward=1. Konfigurasi klasik separuh rosak membenarkan aliran keluar dan melupakan arah balik, sehingga klien menyelesaikan jabat tangan dan kemudian tiada apa dimuatkan; peraturan conntrack untuk trafik yang terjalin dan berkaitan meliputi arah itu.

NAT ialah soalan ketiga. Tanpa penulisan semula dalam postrouting, paket yang dimajukan keluar dengan sumber persendirian terowong dan digugurkan di hulu, kerana tiada rangkaian di luar hos tahu cara menghala kolam itu kembali. Awalan sumber dalam peraturan itu mesti sepadan dengan kolam VPN, bukan alamat hos sendiri, dan perkara yang sama berlaku untuk peraturan pemajuan yang menamakan subnet klien.

IPv6 ialah dasar kedua, bukan fikiran kemudian. Hos dengan rantaian IPv4 yang ketat dan dasar terbuka pada ip6tables belum menutup apa-apa; perkhidmatan masih boleh dicapai melalui keluarga yang satu lagi. Sama ada cerminkan set peraturan dengan ip6tables atau lumpuhkan IPv6 secara sengaja pada antara muka awam, dan tuliskan mana yang anda pilih.

Asas yang boleh dibaca dalam satu laluan

Mulakan dengan penolakan, kemudian tambah hanya apa yang hos perlukan. Pertama loopback dan balasan, kemudian laluan pentadbiran, kemudian pendengar terowong, kemudian dasar pemajuan untuk klien:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Nama antara muka, port dan kolam ialah pemegang tempat; bacalah daripada pelayan dan bukan menyalinnya. Menyimpan hasilnya sama penting dengan menulisnya, kerana set peraturan yang hanya hidup dalam ingatan hilang pada but semula berikutnya dan membuka hos semula secara senyap. Jadikannya kekal dengan mekanisme pengedaran, dan simpan salinan di luar mesin untuk hari mesin itu tidak mahu but.

Menutup port terakhir tanpa kehilangan hos

Ada perangkap dalam reka bentuk. Jika SSH hanya wujud melalui terowong, perkhidmatan VPN yang gagal akan membawa SSH bersamanya, dan satu-satunya jalan kembali mungkin konsol yang tidak pernah anda buka. Sebelum menutup port awam terakhir, pastikan konsol itu wujud dan benar-benar boleh anda gunakan, atau kekalkan satu laluan pentadbiran sempit yang tidak bergantung pada terowong: SSH dari alamat tetap, kunci sahaja, pengesahan kata laluan dimatikan.

Gunakan perubahan itu daripada sesi yang sudah terjalin, bukan melalui sambungan yang anda akan tapis. Jadualkan pengembalian supaya kesilapan luput dan bukan menjadi kekal, contohnya tugas systemd-run --on-active=10min yang memulihkan set peraturan sebelumnya, dan biarkan sesi SSH kedua terbuka semasa anda menguji yang pertama. Kemudian sahkan tugas pengembalian benar-benar tercetus, kerana pemulihan yang tidak diuji sama dengan tiada pemulihan.

Buktikan laluannya, bukan skripnya

Baca peraturan yang dimuatkan, bukan fail yang sepatutnya memuatkannya. Daripada hos luar yang dibenarkan, sahkan bahawa hanya port yang dimaksudkan menjawab; dari dalam terowong, sahkan perkhidmatan yang ingin anda terbitkan boleh dicapai. Dasar tolak-lalai yang turut menyekat trafik terowong kelihatan sama seperti penguncian yang berfungsi sehingga seseorang cuba menggunakannya.

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

Catat port yang dibenarkan, kolam klien, antara muka terowong, sumber pentadbiran dan prosedur konsol di sebelah konfigurasi. Perubahan seterusnya pada kolam atau nama antara muka mesti sepadan dalam penapis dan peraturan NAT, jika tidak hos kembali kepada keadaan separuh terbuka tanpa sesiapa menyedarinya.

Satu tabiat lebih bernilai daripada set peraturan: selepas setiap perubahan, buktikan laluan pemajuan dengan permintaan klien dan buktikan laluan pemulihan dengan sesi kedua. Penguncian yang belum anda gunakan hanyalah hipotesis.