Gerbang VPN di Raspberry Pi: satu kartu jaringan atau port klien khusus

Anda punya satu Pi, satu profil VPN keluar yang berfungsi, dan dua perangkat yang harus mencapai internet melaluinya. Pertanyaan yang menentukan seluruh pembangunan bukanlah panduan mana yang diikuti, melainkan seberapa banyak pengurungan yang Anda butuhkan. Satu port membiarkan Pi berdiri di samping perangkat itu di LAN router dan bertindak sebagai gerbang tambahan; port kedua memungkinkan Anda menempatkannya di segmen di mana Pi adalah satu-satunya jalan keluar. Semua setelah pilihan itu — DHCP, cakupan firewall, DNS, kasus pemutusan — mengalir darinya.

Apa yang sebenarnya membedakan kedua tata letak

Kedua rancangan merutekan. Bedanya adalah siapa lagi yang berdiri di kabel dan apa yang terjadi ketika kebijakan Anda salah.

Pengurungan adalah poros yang sebenarnya. Tata letak A bersifat menasihati: perangkat yang mengabaikan gerbang dari DHCP dan memilih router tetap berfungsi, tetapi tanpa enkripsi. Tata letak B ditegakkan oleh topologi, karena tidak ada lompatan berikutnya lain yang bisa dipilih.

Tata letak A: Pi sebagai gerbang tambahan di LAN yang ada

Misalkan router ISP adalah 192.168.50.1, Pi adalah 192.168.50.2, dan klien terpilih mengarah ke Pi. Yang penting adalah dua aliran paket berbeda berbagi satu kabel. Paket dalam klien tiba di Pi dan harus keluar melalui terowongan; paket terenkripsi Pi sendiri ke rekan VPN harus keluar melalui kabel yang sama ke router. Keduanya bergerak berlawanan arah pada antarmuka yang sama dan memerlukan perlakuan berbeda.

Beri Pi alamatnya melalui manajer jaringan yang terpasang, bukan resep berkas antarmuka lama yang bersaing dengannya untuk perangkat itu. Lalu atur klien: gerbang statis pada satu perangkat, atau reservasi DHCP yang memberikan 192.168.50.2 sebagai router. Jangan ubah seluruh cakupan DHCP router demi dua perangkat, dan jangan menganggap klien menghormati opsi itu — verifikasi.

Kelemahannya struktural, bukan dapat diperbaiki. Setiap klien di segmen itu dapat mengarah ke 192.168.50.1 dan keluar tanpa enkripsi, dan perangkat dengan antarmuka kedua atau radio seluler meninggalkan jalur penegakan Anda sepenuhnya. Jika kalimat itu tidak dapat diterima untuk perangkat yang bersangkutan, Anda sudah punya jawabannya: gunakan tata letak B.

Tata letak B: port khusus mengurung perangkat di dalam

Di sini Pi mempertahankan 192.168.50.2 pada uplink dengan gerbang 192.168.50.1, dan mengambil 10.20.0.1/24 pada antarmuka kedua untuk perangkat yang terpasang. Pi sekarang menjadi router dengan dua jaringan, dan segmen terpasang memiliki tepat satu jalan keluar.

Periksa rentang terhadap semua yang lain sebelum berkomitmen: subnet terowongan itu sendiri, prefiks antar-situs lain, dan apa pun yang dapat dijangkau melalui VPN. 10.20.0.0/24 yang bertabrakan dengan LAN jauh menghasilkan hasil setengah berfungsi yang butuh satu malam untuk didiagnosis. Jika port kedua adalah adaptor USB, pastikan didukung dan patok namanya di manajer jaringan agar penataan ulang setelah boot tidak memindahkan alamat LAN Anda.

Jalankan pendengar DHCP hanya pada antarmuka itu. Server yang menjawab di uplink bersaing dengan router ISP dan membagikan alamat segmen Anda ke seluruh rumah. Ikat ke antarmuka LAN, batasi ke rentang yang dideklarasikan, dan jaga alamat Pi sendiri di luar kumpulan.

Penerusan, penerjemahan, dan aturan penutupan saat gagal

Empat hal sering dijelaskan sebagai satu dan bukan. Mengaktifkan penerusan (net.ipv4.ip_forward=1) hanya memberi tahu kernel bahwa ia boleh memindahkan paket antar antarmuka; itu sendiri tidak mengizinkan apa pun dan tidak menjamin jalur apa pun. Memilih egress adalah keputusan perutean. Mengizinkan paket adalah keputusan kebijakan pada rantai forward. Menulis ulang sumbernya adalah keputusan postrouting. Bangunan yang hanya melakukan yang pertama menghasilkan Pi yang dengan senang hati meneruskan lalu lintas klien keluar melalui uplink.

Batasi izin pada sumber yang Anda maksud dan pada antarmuka yang harus digunakan lalu lintas, serta sertakan jalur balik dan tujuan yang Pi butuhkan. Lalu terjemahkan di egress terowongan jika penyedia tidak merutekan prefiks LAN Anda kembali kepada Anda. manual nftables memperlakukan penerusan, keluaran lokal, dan penerjemahan sumber sebagai operasi terpisah, yang merupakan model mental yang benar di sini.

Kegagalan umum adalah aturan masquerade lebar pada antarmuka fisik. Lalu lintas mencapai internet melalui jalur ISP sementara dari sisi klien tampak persis seperti VPN yang berfungsi. Itu tidak membuktikan apa pun. Jaga penerjemahan tetap terikat pada egress yang dideklarasikan, dan simpan aturan Anda di firewall yang sudah dipakai host alih-alih menambahkan kumpulan aturan pesaing yang mengosongkan rantai postrouting bersama.

Lalu tangani ketiadaan terowongan. Profil klien yang memasang rute default lebar juga berarti bahwa ketika terowongan putus, default biasa dapat kembali dan lalu lintas klien diam-diam kembali ke uplink. Di mana kembali ke teks polos tidak dapat diterima, kebijakan forward harus menolak secara eksplisit lalu lintas dari klien ke uplink, dalam keadaan di mana rute VPN telah hilang. Tulis itu sebagai aturan tolak, bukan sebagai asumsi. Transportasi terenkripsi Pi sendiri ke rekan VPN adalah aliran local-output terpisah dan harus tetap diizinkan, atau terowongan tidak akan pernah bisa kembali.

DNS dan IPv6 perlu jawaban sendiri

Jika klien memakai Pi sebagai penyelesai, mereka mencapai pendengar lokal dan Pi memulai kueri baru. Kueri hulu itu mengikuti rute Pi sendiri, bukan aturan forward yang Anda tulis untuk klien, jadi jalur klien hanya melalui terowongan ditambah penyelesai yang keluar langsung adalah kebocoran tanpa pesan galat apa pun. Putuskan dengan sengaja: penyelesai yang dijangkau melalui terowongan, atau yang lokal yang Anda terima sebagai langsung, dan sesuaikan kebijakan keluaran Pi sendiri dengan keputusan itu.

IPv6 lagi-lagi kasus terpisah. Aturan forward untuk IPv4 tidak membatasi apa pun tentang IPv6, dan pengumuman router di uplink dapat memberi Pi, dan melaluinya segmen terpasang, default kedua yang melewati kebijakan Anda. Entah beri IPv6 jalur terlindunginya sendiri dengan prinsip yang sama, atau batasi secara eksplisit di segmen klien dan katakan begitu.

Uji batasnya sebelum Anda mempercayainya

Terima rancangan hanya setelah empat pemeriksaan terpisah, karena uji tunggal yang menggoda — membuka peramban pada satu klien — lolos dalam beberapa keadaan rusak.

Pastikan satu klien nyata mencapai internet melalui terowongan, lalu pastikan klien yang sama tidak dapat mencapai internet saat terowongan mati. Pastikan resolusi DNS berfungsi dan kueri keluar ke tempat yang Anda maksud. Pastikan transportasi Pi sendiri masih berfungsi setelah mulai ulang terowongan, dan pemulihan tidak memerlukan boot ulang mesin. Terakhir, periksa perangkat yang tidak Anda pilih: pada tata letak A perangkat itu harus tetap berfungsi normal, dan pada tata letak B perangkat itu seharusnya tidak ada sama sekali di segmen itu.

• Dua port dan aturan tolak memberi penegakan; satu port dan opsi DHCP memberi nasihat.
• Penerjemahan pada antarmuka yang salah tampak seperti keberhasilan dan bukan.
• Lalu lintas Pi sendiri, DNS, dan IPv6 masing-masing butuh keputusan, bukan kesimpulan.