Batasi aturan SNAT OpenVPN sebelum merusak nginx

Dua kegagalan terus datang dari jenis host yang sama. Pada yang pertama, klien terautentikasi lalu tidak mencapai apa pun di luar terowongan. Pada yang kedua, VPN naik dan situs web server itu sendiri berhenti menjawab, yang lebih mengkhawatirkan karena tampak seperti kerusakan sampingan. Pada VPS berbasis kontainer keduanya biasanya kembali ke daftar periksa pendek yang sama, dan urutannya penting: perangkat dulu, penerjemahan kedua, cakupan ketiga.

Pastikan kontainer dapat membuat perangkat tun

Tidak ada yang lain penting jika antarmuka terowongan tidak dapat ada. Periksa bahwa /dev/net/tun ada dan pembuatan perangkat uji berhasil, karena banyak penyedia menonaktifkan tun di dalam kontainer secara bawaan. Tidak ada pekerjaan firewall yang mengimbangi perangkat yang tidak pernah dibuat.

Jika perangkat hilang, hanya host atau penyedia yang dapat mengaktifkannya. Paket lain sering lebih murah daripada utas dukungan terbuka yang berlangsung seminggu. Pastikan ini sebelum Anda membaca satu baris log OpenVPN. Jika tidak, Anda menghabiskan malam menyetel aturan yang tidak akan pernah melihat paket.

Putuskan apa yang dilakukan MASQUERADE pada antarmuka ini

Pada mesin virtual biasa, aturan keluar yang lazim adalah POSTROUTING MASQUERADE dari antarmuka utama. Di kontainer OpenVZ perangkat yang terlihat sering kali venet0, antarmuka virtual yang dikelola host dan bukan NIC yang dirutekan, dan MASQUERADE tidak selalu berperilaku di sana seperti yang diasumsikan tutorial.

Bentuk yang bisa dipakai adalah penerjemahan eksplisit ke alamat yang sudah dijangkau klien, dengan penerusan diizinkan di kedua arah. Mengganti pool dari konfigurasi server sama pentingnya dengan mengganti alamat. Baca setiap baris sebelum menempelkannya.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Tanpa aturan penerusan, penerjemahan tetap terjadi dan kernel tetap menolak meneruskan. Kombinasi itu menghasilkan keadaan membingungkan saat penghitung pada aturan NAT naik sementara klien tidak menerima apa pun. Kedua baris FORWARD juga harus berada sebelum aturan drop yang luas di rantai yang sama. Urutan adalah bagian dari konfigurasi, bukan detail implementasi.

Batasi aturan ke satu pool dan satu antarmuka

Gejala kedua punya penyebab lain: aturan POSTROUTING tanpa pembatasan sumber maupun keluar. Aturan seperti itu menulis ulang setiap paket yang meninggalkan host.

Layanan yang bergantung pada sumber asli lalu berperilaku salah. Server web di belakang proxy lokal bisa berhenti menjawab, dan memulainya ulang tidak mengubah apa pun karena aturannya masih ada di jalur. Lalu lintas yang dikirim host ke alamat publiknya sendiri juga terdampak, itulah sebabnya kegagalan bisa tampak seperti masalah DNS atau sertifikat, bukan firewall. Aturan itu hampir pasti ditambahkan untuk memperbaiki gejala pertama.

Solusinya adalah mempersempit kecocokan ke pool terowongan dan antarmuka keluar, lalu menambahkan satu aturan per pool alih-alih memperlebar satu aturan untuk mencakup beberapa.

Buat aturan bertahan dan cari tahu siapa lagi yang memilikinya

Aturan yang ditambahkan manual hilang saat reboot, jadi simpan dengan iptables-save atau kelola melalui netfilter-persistent di tempat perangkat itu terpasang. Pastikan pemulihan berjalan sebelum OpenVPN mulai. Lalu reboot sekali dengan sengaja alih-alih menemukan celahnya saat insiden.

Pada host kontainer, pastikan juga berkas persistensi berada di penyimpanan kontainer yang dapat ditulis dan penyedia tidak mengganti penyaringan saat boot. Beberapa platform mengelola kebijakan di luar kontainer, tempat aturan lokal diabaikan atau bertabrakan dengan aturan host itu sendiri.

Verifikasi dengan penghitung dan satu aliran yang ditangkap

Dari klien yang terhubung, periksa alamat publik yang dilaporkan layanan eksternal. Jika cocok dengan alamat server, penerjemahan bekerja; jika tidak, paket keluar lewat jalur lain atau tidak keluar sama sekali. Lalu uji layanan yang dihosting di server dan layanan di internet publik, karena keduanya menempuh jalur berbeda melalui kumpulan aturan yang sama.

Di server, baca penghitung paket pada aturan NAT dan FORWARD dengan iptables -t nat -L -v -n dan amati satu aliran dalam tangkapan. Jika alamat klien muncul di tangkapan dan tidak ada balasan yang menyusul, celahnya ada di jalur kembali atau di penyaringan penyedia, bukan di profil klien. Bandingkan sumber yang ditangkap dengan alamat tujuan penerjemahan aturan, karena ketidakcocokan berarti aturan lain cocok lebih dulu. Satu aliran yang diamati menyelesaikan lebih banyak daripada satu halaman membaca konfigurasi.

Simpan pool, alamat hasil penerjemahan, dan nama antarmuka bersama dalam catatan perubahan. Aturan yang benar untuk satu pool salah menerjemahkan pool berikutnya.