Zon VPN OpenWrt, pemajuan dan penyamaran: yang mana perlu?

Tiga perubahan bercampur setiap kali VPN bertemu OpenWrt: membuka port, membenarkan pemajuan dan menghidupkan penyamaran. Semuanya menjawab soalan berbeza, dan biasanya hanya satu daripadanya keperluan sebenar. Membaca setiap kawalan mengikut peranan trafik yang dikawalnya menukar tekaan menjadi keputusan, dan juga memberitahu gejala apa yang perlu dijangka apabila perubahan itu salah. Mulakan dengan menamakan peranan yang gagal, bukan kotak semak yang anda ingat.

Namakan peranan trafik sebelum menyentuh kawalan

Input zon menentukan apa yang boleh sampai ke penghala itu sendiri. Output zon meliputi trafik yang dihasilkan penghala, pemajuan zon ialah nilai lalai untuk trafik yang melalui sesuatu zon, dan penyamaran menentukan sama ada alamat sumber ditulis semula semasa keluar. Itu empat soalan berbeza, dan dasar zon menjawab kesemuanya sekali gus dengan nilai yang sama, sebab itulah perubahan seluruh zon ialah alat kasar. Peraturan bernama boleh menjawab salah satunya tanpa menyentuh yang lain.

Peta yang berguna ialah mengikut peranan trafik, kerana itulah yang boleh anda perhatikan apabila sesuatu gagal. Setiap peranan di bawah mempunyai satu kawalan yang menentukannya dan satu gejala yang menunjuk kepadanya:

Pendengar pada penghala memerlukan satu peraturan input yang sempit

Pelayan OpenVPN pada penghala menerima trafik yang dialamatkan kepada penghala, jadi sambungan luarnya bergantung pada dasar input zon yang membawanya. Benarkan pengangkutan dan port yang dikonfigurasikan dan biarkan segala-galanya di zon itu ditolak. Satu peraturan port ialah perubahan yang jauh lebih kecil daripada kebenaran seluruh zon, dan itulah yang masih boleh anda jelaskan setahun kemudian.

Dua perkara menjadikan peraturan itu selamat dikekalkan: ia menamakan port yang benar-benar digunakan oleh perkhidmatan, dan ia terletak di sebelah definisi zon supaya orang seterusnya melihat mengapa ia wujud. Baris di bawah hanyalah bentuknya, dengan port mewakili apa yang dikonfigurasikan pada pelayan. Tukar port itu di kedua-dua tempat apabila perkhidmatan berpindah, kerana peraturan yang ditinggalkan pada yang lama tidak kelihatan sehingga audit.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Sahkan sebelum memuat semula, kerana ralat sintaks dalam fail tembok api boleh meninggalkan penghala tanpa set peraturan yang berfungsi. Pada keluaran yang menggunakan fw4, semakan ialah arahan berasingan, dan ia gagal dengan lantang dan bukannya menerima blok rosak secara senyap. Muat semula hanya selepas semakan lulus, dan simpan fail sebelumnya di tempat yang anda boleh kembalikannya.

fw4 check
service firewall reload

Permintaan klien melalui pemajuan, bukan input

Selepas pengesahan, permintaan pelanggan terowong untuk perkhidmatan LAN menghasilkan aliran yang dimajukan, jadi kawalan yang menentukannya ialah hubungan pemajuan antara zon terowong dan zon LAN. Berikan antara muka terowong kepada zon yang dimaksudkan, kemudian isytiharkan arah, sumber dan perkhidmatan. Penetapan zon itulah yang memberi makna kepada peraturan pemajuan, dan kedua-duanya hanya masuk akal apabila dibaca bersama. Hubungan pemajuan yang menamakan zon terowong sebagai sumber dan zon LAN sebagai destinasi dibaca sebagai satu keputusan yang disengajakan, manakala dua kebenaran seluruh zon dibaca sebagai kemalangan.

Mencapai penghala itu sendiri masih menggunakan laluan input, sebab itulah ping ke gerbang tidak mengatakan apa-apa tentang perkongsian fail di belakangnya. Kedua-dua kegagalan itu hidup dalam blok berbeza dan diperbaiki dengan perubahan berbeza. Tulis kedua-dua laluan secara berasingan sebelum menukar mana-mana satu.

Penyamaran ialah keputusan penghalaan, bukan kebenaran

Penyamaran menulis semula alamat sumber trafik keluar terpilih. Ia boleh menyelamatkan reka bentuk keluar yang pihak jauhnya tiada laluan balik, dan ia juga menyembunyikan alamat pelanggan individu daripada mana-mana perkhidmatan yang merekod atau membenarkan berdasarkan alamat. Mematikannya ialah pilihan penghalaan tentang laluan balik, bukan suis keselamatan yang menutup lubang masuk. Terowong yang berfungsi dengan terjemahan dihidupkan dan gagal pada saat ia dimatikan biasanya kekurangan laluan balik, bukan peraturan tembok api.

Alternatif yang dihalakan memerlukan laluan balik di pihak jauh dan bukannya terjemahan. Kedua-dua pilihan tidak menyediakan kebenaran tembok api atau akaun aplikasi, sebab itulah mematikan penyamaran hampir tidak pernah membaiki pelanggan terowong yang tidak dapat mencapai apa-apa. Tangani dasar IPv4 dan IPv6 secara berasingan juga, kerana satu tetapan terjemahan tidak menggambarkan kedua-dua keluarga.

Buktikan keputusan dengan permintaan dibenarkan dan ditolak

Hantar satu permintaan yang sepatutnya dibenarkan dan satu yang sepatutnya ditolak, kemudian kenal pasti kawalan yang membuat setiap keputusan. Halaman yang dimuatkan secara kebetulan bukan bukti; buktinya ialah peraturan yang sepadan, dalam rantaian tempat ia sepadan. Penolakan itu sama pentingnya dengan kejayaan, kerana ia menunjukkan dasar itu melakukan sesuatu dan bukannya semuanya dibenarkan.

Dua arahan memberikan bukti itu pada keluaran semasa. Pembilang pada peraturan yang sepadan bergerak apabila permintaan diterima, dan log menunjukkan penurunan jika anda mengaktifkan pengelogan untuk peraturan itu:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Kekalkan laluan pentadbiran yang masih boleh anda gunakan sebelum menukar mana-mana dasar tembok api, dan ikut proses pengesahan serta pengembalian pemilik konfigurasi. Perubahan yang mengunci anda di luar penghala bukan hasil ujian, ia insiden kedua. Catat zon dan peranan trafik di sebelah setiap pemerhatian, supaya pasangan hasil menjelaskan dasar itu dan bukannya menggambarkan pemuatan halaman yang bertuah.