Klien VPN dan LAN: bila hendak guna zon berasingan

Meletakkan antara muka terowong dalam zon LAN ialah laluan terpendek ke VPN yang berfungsi, dan biasanya itulah nilai lalai yang salah. Ia memberi klien jauh kepercayaan yang sama seperti LAN berwayar, sedangkan tugasan jarang memerlukannya. Zon berasingan berharga beberapa peraturan dan menjadikan sempadan kelihatan. Keputusannya bukan sama ada zon lebih baik; tetapi tiga syarat manakah yang terpakai pada rangkaian anda.

Nama zon tidak menyulitkan apa-apa dan tidak mengesahkan pengguna. Ia hanya mengelompokkan antara muka untuk model dasar tembok api.

Apa yang sebenarnya dikawal oleh keahlian zon

Zon mengelompokkan antara muka atau trafik dalam model tembok api. Tetapan input, output dan forwardnya kemudian mengawal peranan yang berbeza. Input ialah trafik ke penghala itu sendiri; forward ialah trafik melaluinya ke hos lain. Dokumentasi zon OpenWrt menganggap input, output dan forward sebagai tetapan berasingan kerana sebab itu juga.

Kebenaran dari zon VPN ke zon LAN bukan automatik kebenaran sebaliknya. Peraturan forward bersifat berarah, dan peraturan yang membenarkan trafik klien ke pelayan tidak membenarkan sesi pelayan ke klien. Klien yang boleh membuka sambungan ke pelayan bukan klien yang boleh dibuka sambungan balik oleh pelayan.

Perbezaan itulah sebab zon berasingan berguna: anda boleh menyatakan setiap arah dan setiap peranan secara jelas. Tulis arah di sebelah setiap peraturan.

Keputusan satu: input, forward atau kedua-duanya

Jika klien jauh memerlukan DNS daripada penghala, benarkan input untuk perkhidmatan itu sahaja. Jika mereka perlu mencapai pelayan fail, benarkan forward ke destinasi itu. Kebanyakan reka bentuk VPN memerlukan kedua-duanya, tetapi untuk perkhidmatan yang berbeza.

Akses input yang luas ke setiap perkhidmatan tempatan hampir tidak pernah diperlukan. Layan pengurusan penghala sebagai keputusan berasingan daripada akses aplikasi. Jika penghala hanya perlu menjawab DNS, tulis kebenaran tunggal itu dan biarkan selebihnya tertutup.

Keputusan dua: sumber apa yang diperlukan klien jauh

Senaraikan julat klien, destinasi dan perkhidmatan yang perlu disediakan VPN sebelum menulis peraturan. Senarai destinasi lebih berguna daripada label kepercayaan, kerana ia bertahan melalui penghijrahan tembok api.

Jauhkan antara muka pengurusan daripada akses aplikasi biasa. Klien jauh yang mencapai wiki tidak dengan itu memerlukan halaman pentadbir penghala atau konsol hypervisor.

Jika destinasi yang dibenarkan boleh meneruskan lebih jauh, sempadan zon berhenti di tembok api, bukan pada apa yang destinasi lakukan selepas itu.

Keputusan tiga: bagaimana anda membuktikan sempadan

Uji aliran yang dibenarkan dan satu yang sengaja ditolak selepas setiap perubahan. Membuktikan satu laman web dimuatkan tidak mendedahkan kebenaran luas yang tidak disengajakan. Uji dari julat alamat klien VPN, bukan dari LAN, dan sertakan arah yang anda jangka akan gagal. Catat kedua-dua hasil di sebelah peraturan.

Pelihara akses pemulihan gerbang sebelum mengubah dasar zon jauh. Gunakan konfigurasi terurus yang berterusan dan bukan suntingan semasa berjalan, jika tidak but semula seterusnya akan memulihkan kepercayaan lama. Salinan konfigurasi sebelumnya, disimpan di luar peranti, ialah pengunduran termurah yang akan anda miliki.

Apabila rangkaian berkembang, dokumentasikan keahlian dan tujuan peraturan. Antara muka yang baru dipasang tidak sepatutnya mewarisi keistimewaan hanya kerana seseorang memberinya nama zon yang mudah.