Hadkan peraturan SNAT OpenVPN sebelum ia merosakkan nginx

Dua kegagalan terus datang daripada jenis hos yang sama. Pada yang pertama, klien disahkan dan kemudian tidak mencapai apa-apa di luar terowong. Pada yang kedua, VPN naik dan tapak web pelayan itu sendiri berhenti menjawab, yang lebih membimbangkan kerana ia kelihatan seperti kerosakan sampingan. Pada VPS berasaskan kontena kedua-duanya biasanya kembali kepada senarai semak pendek yang sama, dan urutan penting: peranti dahulu, terjemahan kedua, skop ketiga.

Sahkan kontena boleh mencipta peranti tun

Tiada apa-apa lagi yang penting jika antara muka terowong tidak boleh wujud. Semak bahawa /dev/net/tun hadir dan penciptaan peranti ujian berjaya, kerana banyak penyedia melumpuhkan tun di dalam kontena secara lalai. Tiada kerja firewall boleh menggantikan peranti yang tidak pernah dicipta.

Jika peranti tiada, hanya hos atau penyedia boleh mengaktifkannya. Pelan lain selalunya lebih murah daripada urutan sokongan terbuka yang berlangsung seminggu. Sahkan ini sebelum anda membaca satu baris log OpenVPN. Jika tidak, anda akan menghabiskan malam menala peraturan yang tidak akan pernah melihat paket.

Tentukan apa yang MASQUERADE lakukan pada antara muka ini

Pada mesin maya biasa, peraturan keluar lazim ialah POSTROUTING MASQUERADE daripada antara muka utama. Dalam kontena OpenVZ peranti yang kelihatan selalunya venet0, antara muka maya yang diuruskan hos dan bukan NIC yang dihalakan, dan MASQUERADE tidak sentiasa berkelakuan di situ seperti yang diandaikan tutorial.

Bentuk yang boleh dilaksanakan ialah terjemahan eksplisit ke alamat yang sudah dicapai klien, dengan pemajuan dibenarkan dalam kedua-dua arah. Menggantikan pool daripada konfigurasi pelayan sama pentingnya dengan menggantikan alamat. Baca setiap baris sebelum menampalnya.

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 peraturan pemajuan, terjemahan masih berlaku dan kernel masih enggan memajukan. Gabungan itu menghasilkan keadaan mengelirukan apabila pembilang pada peraturan NAT naik sementara klien tidak menerima apa-apa. Kedua-dua baris FORWARD juga mesti berada sebelum mana-mana peraturan drop yang luas dalam rantai yang sama. Urutan adalah sebahagian daripada konfigurasi, bukan perincian pelaksanaan.

Hadkan peraturan kepada satu pool dan satu antara muka

Gejala kedua mempunyai punca lain: peraturan POSTROUTING tanpa sekatan sumber mahupun sekatan keluaran. Peraturan sedemikian menulis semula setiap paket yang meninggalkan hos.

Perkhidmatan yang bergantung pada sumber asal kemudian berkelakuan salah. Pelayan web di belakang proksi tempatan boleh berhenti menjawab, dan memulakannya semula tidak mengubah apa-apa kerana peraturan itu masih di laluan. Trafik yang dihantar hos ke alamat awamnya sendiri juga terjejas, itulah sebabnya kegagalan boleh kelihatan seperti masalah DNS atau sijil dan bukan firewall. Peraturan itu hampir pasti ditambah untuk membaiki gejala pertama.

Penyelesaiannya ialah menyempitkan padanan kepada pool terowong dan antara muka keluar, kemudian menambah satu peraturan bagi setiap pool dan bukannya meluaskan satu peraturan untuk meliputi beberapa.

Jadikan peraturan kekal dan ketahui siapa lagi yang memilikinya

Peraturan yang ditambah secara manual hilang semasa reboot, jadi simpannya dengan iptables-save atau uruskannya melalui netfilter-persistent di tempat ia dipasang. Sahkan pemulihan berjalan sebelum OpenVPN bermula. Kemudian but semula sekali dengan sengaja dan bukannya menemui jurang semasa insiden.

Pada hos kontena, sahkan juga fail kegigihan berada dalam storan kontena yang boleh ditulis dan penyedia tidak menggantikan penapisan semasa but. Sesetengah platform mengurus dasar di luar kontena, di mana peraturan tempatan sama ada diabaikan atau bertembung dengan peraturan hos itu sendiri.

Sahkan dengan pembilang dan satu aliran yang ditangkap

Daripada klien yang disambungkan, semak alamat awam yang dilaporkan oleh perkhidmatan luaran. Jika ia sepadan dengan alamat pelayan, terjemahan berfungsi; jika tidak, paket keluar melalui laluan lain atau tidak keluar sama sekali. Kemudian uji kedua-dua perkhidmatan yang dihoskan pada pelayan dan satu di internet awam, kerana kedua-duanya mengambil laluan berbeza melalui set peraturan yang sama.

Pada pelayan, baca pembilang paket pada peraturan NAT dan FORWARD dengan iptables -t nat -L -v -n dan perhatikan satu aliran dalam tangkapan. Jika alamat klien muncul dalam tangkapan dan tiada balasan menyusul, jurang itu ada pada laluan balik atau dalam penapisan penyedia, bukan dalam profil klien. Bandingkan sumber yang ditangkap dengan alamat yang diterjemah oleh peraturan, kerana ketidakpadanan bermakna peraturan lain sepadan dahulu. Satu aliran yang diperhatikan menyelesaikan lebih daripada satu halaman bacaan konfigurasi.

Simpan pool, alamat terjemahan dan nama antara muka bersama dalam rekod perubahan. Peraturan yang betul untuk satu pool tersilap menterjemah yang seterusnya.