Gerbang VPN pada Raspberry Pi: satu kad rangkaian atau port klien khusus

Anda mempunyai satu Pi, satu profil VPN keluar yang berfungsi dan dua peranti yang sepatutnya mencapai internet melaluinya. Soalan yang menentukan seluruh pembinaan bukanlah panduan mana yang perlu diikuti, tetapi berapa banyak pengurungan yang anda perlukan. Satu port membenarkan Pi berdiri di sebelah peranti itu pada LAN penghala dan bertindak sebagai gerbang tambahan; port kedua membenarkan anda meletakkannya pada segmen di mana Pi ialah satu-satunya jalan keluar. Segala-galanya selepas pilihan itu — DHCP, skop tembok api, DNS, kes gangguan — berpunca daripadanya.

Apakah sebenarnya yang membezakan kedua-dua susun atur

Kedua-dua reka bentuk menghala. Bezanya ialah siapa lagi yang berdiri di atas kabel dan apa yang berlaku apabila dasar anda salah.

Pengurungan ialah paksi sebenar. Susun atur A bersifat nasihat: peranti yang mengabaikan gerbang yang diberi DHCP dan memilih penghala masih berfungsi, tetapi tanpa penyulitan. Susun atur B dikuatkuasakan oleh topologi, kerana tiada lonjakan seterusnya yang lain untuk dipilih.

Susun atur A: Pi sebagai gerbang tambahan pada LAN sedia ada

Katakan penghala ISP ialah 192.168.50.1, Pi ialah 192.168.50.2, dan klien yang dipilih menunjuk ke Pi. Yang penting ialah dua aliran paket berbeza berkongsi satu kabel. Paket dalaman klien tiba di Pi dan mesti keluar melalui terowong; paket tersulit Pi sendiri ke rakan VPN mesti keluar melalui kabel yang sama ke penghala. Kedua-duanya bergerak dalam arah bertentangan pada antara muka yang sama dan memerlukan layanan berbeza.

Berikan Pi alamatnya melalui pengurus rangkaian yang dipasang, bukan melalui resipi fail antara muka lama yang bersaing dengannya untuk peranti itu. Kemudian tetapkan klien: gerbang statik pada satu peranti, atau tempahan DHCP yang memberikan 192.168.50.2 sebagai penghala. Jangan ubah seluruh skop DHCP penghala kerana dua peranti, dan jangan andaikan klien menghormati pilihan itu — sahkan.

Kelemahannya bersifat struktur, bukan boleh diperbaiki. Mana-mana klien pada segmen itu boleh menunjuk ke 192.168.50.1 dan keluar dalam teks jelas, dan peranti dengan antara muka kedua atau radio selular meninggalkan laluan penguatkuasaan anda sepenuhnya. Jika ayat itu tidak boleh diterima untuk peranti berkenaan, anda sudah ada jawapannya: gunakan susun atur B.

Susun atur B: port khusus mengurung peranti di dalam

Di sini Pi mengekalkan 192.168.50.2 pada pautan atas dengan gerbang 192.168.50.1, dan mengambil 10.20.0.1/24 pada antara muka kedua untuk peranti yang disambungkan. Kini Pi ialah penghala dengan dua rangkaian, dan segmen yang disambungkan mempunyai tepat satu jalan keluar.

Semak julat itu terhadap segala yang lain sebelum anda komited: subnet terowong itu sendiri, awalan antara tapak lain dan apa-apa yang boleh dicapai melalui VPN. 10.20.0.0/24 yang berlanggar dengan LAN jauh menghasilkan keputusan separuh berfungsi yang mengambil masa satu malam untuk didiagnosis. Jika port kedua ialah penyesuai USB, sahkan ia disokong dan tetapkan namanya dalam pengurus rangkaian supaya penyusunan semula selepas but semula tidak menggerakkan alamat LAN anda.

Jalankan pendengar DHCP pada antara muka itu sahaja. Pelayan yang menjawab pada pautan atas bersaing dengan penghala ISP dan mengagihkan alamat segmen anda kepada seluruh rumah. Ikatkannya pada antara muka LAN, hadkan kepada julat yang diisytiharkan, dan kekalkan alamat Pi sendiri di luar kumpulan.

Pemajuan, terjemahan dan peraturan penutupan semasa kegagalan

Empat perkara sering digambarkan sebagai satu dan sebenarnya bukan. Mengaktifkan pemajuan (net.ipv4.ip_forward=1) hanya memberitahu kernel bahawa ia boleh memindahkan paket antara antara muka; ia sendiri tidak membenarkan apa-apa dan tidak menjamin sebarang laluan. Memilih egress ialah keputusan penghalaan. Membenarkan paket ialah keputusan dasar dalam rantaian forward. Menulis semula sumbernya ialah keputusan postrouting. Pembinaan yang hanya melakukan yang pertama menghasilkan Pi yang dengan gembira memajukan trafik klien keluar melalui pautan atas.

Hadkan kebenaran kepada sumber yang anda maksudkan dan kepada antara muka yang trafik patut gunakan, dan sertakan laluan balik serta destinasi yang Pi perlukan. Kemudian terjemahkan pada egress terowong jika penyedia tidak menghala awalan LAN anda kembali kepada anda. manual nftables menganggap pemajuan, output setempat dan terjemahan sumber sebagai operasi berasingan, dan itulah model mental yang betul di sini.

Kegagalan biasa ialah peraturan masquerade luas pada antara muka fizikal. Trafik kemudian mencapai internet melalui laluan ISP sementara dari sisi klien ia kelihatan tepat seperti VPN yang berfungsi. Itu tidak membuktikan apa-apa. Kekalkan terjemahan terikat pada egress yang diisytiharkan, dan simpan peraturan anda dalam tembok api yang sudah digunakan hos, bukannya menambah set peraturan pesaing yang mengosongkan rantaian postrouting bersama.

Kemudian tangani ketiadaan terowong. Profil klien yang memasang laluan lalai luas juga bermakna apabila terowong jatuh, lalai biasa boleh kembali dan trafik klien senyap-senyap kembali ke pautan atas. Di mana kemunduran kepada teks jelas tidak boleh diterima, dasar forward mesti menolak secara eksplisit trafik dari klien ke pautan atas, dalam keadaan di mana laluan VPN telah hilang. Tulisnya sebagai peraturan penolakan, bukan andaian. Pengangkutan tersulit Pi sendiri ke rakan VPN ialah aliran local-output berasingan dan mesti kekal dibenarkan, jika tidak terowong tidak akan kembali.

DNS dan IPv6 memerlukan jawapan mereka sendiri

Jika klien menggunakan Pi sebagai penyelesai, mereka sampai ke pendengar setempat dan Pi memulakan pertanyaan baharu. Pertanyaan huluan itu mengikut laluan Pi sendiri, bukan peraturan forward yang anda tulis untuk klien, jadi laluan klien hanya melalui terowong ditambah penyelesai yang keluar terus ialah kebocoran tanpa sebarang mesej ralat. Putuskan dengan sengaja: penyelesai yang dicapai melalui terowong, atau yang setempat yang anda terima sebagai terus, dan sesuaikan dasar output Pi sendiri dengan keputusan itu.

IPv6 sekali lagi kes berasingan. Peraturan forward untuk IPv4 tidak mengehadkan apa-apa tentang IPv6, dan pengumuman penghala pada pautan atas boleh memberi Pi, dan melaluinya segmen yang disambungkan, lalai kedua yang memintas dasar anda. Sama ada beri IPv6 laluan terlindungnya sendiri dengan prinsip yang sama, atau hadkannya secara eksplisit pada segmen klien dan katakan begitu.

Uji sempadan sebelum anda mempercayainya

Terima reka bentuk hanya selepas empat pemeriksaan berasingan, kerana ujian tunggal yang menggoda — membuka pelayar pada satu klien — lulus dalam beberapa keadaan rosak.

Sahkan bahawa satu klien sebenar mencapai internet melalui terowong, kemudian sahkan bahawa klien yang sama tidak dapat mencapai internet apabila terowong turun. Sahkan bahawa penyelesaian DNS berfungsi dan pertanyaan keluar ke tempat yang anda maksudkan. Sahkan bahawa pengangkutan Pi sendiri masih berfungsi selepas terowong dimulakan semula, dan pemulihan tidak memerlukan but semula mesin. Akhir sekali, periksa peranti yang anda tidak pilih: dalam susun atur A ia patut terus berfungsi seperti biasa, dan dalam susun atur B ia sepatutnya tidak wujud sama sekali pada segmen itu.

• Dua port dan peraturan penolakan memberikan penguatkuasaan; satu port dan pilihan DHCP memberikan nasihat.
• Terjemahan pada antara muka yang salah kelihatan seperti kejayaan dan bukan.
• Trafik Pi sendiri, DNS dan IPv6 masing-masing memerlukan keputusan, bukan kesimpulan.