hostapd dan OpenVPN di Satu Pi: Siapa Pemilik Rute Default?

Ponsel terhubung ke titik akses, menerima alamat, lalu tidak mencapai apa pun begitu tunnel naik. hostapd biasanya sehat dalam keadaan itu, dan OpenVPN juga; yang rusak adalah rute default, yang entah tidak pernah ada di bridge atau digantikan oleh tunnel tanpa meninggalkan jalur ke server VPN itu sendiri. Panduan ini mengembalikan rute itu ke tempatnya dan membuktikan hasilnya dari klien, bukan dari Pi. Setiap langkah dapat dibatalkan, dan tidak ada yang di sini mengubah konfigurasi tunnel sampai Anda tahu lalu lintas apa yang Anda inginkan di dalamnya.

Inventarisasi antarmuka sebelum Anda mengubah apa pun

Tata letak yang lazim menempatkan radio nirkabel dan porta kabel di dalam br0, menjalankan hostapd terhadap bridge dan membagikan sewa dari dnsmasq, sementara klien OpenVPN membuat tun0. Lalu tiga persyaratan terpisah tampak seperti satu: klien titik akses membutuhkan Pi sebagai gateway mereka, Pi membutuhkan rute ke internet untuk menjangkau servernya, dan bridge membutuhkan alamat gateway yang dapat dipakai klien tersebut.

Baca keadaan saat ini sebelum mengubahnya, karena empat perintah ini memisahkan masalah antarmuka dari masalah perutean.

ip -br addr
ip route show
ip link show master br0
bridge link show

Jika br0 membawa alamat tetapi tidak punya rute default, klien menjangkau Pi dan tidak ada apa pun di luarnya. Jika rute default menunjuk ke tun0 saat tunnel mati, Pi sama sekali tidak punya jalur yang berfungsi, dan gejala klien tampak persis sama. Kedua kasus terlihat identik dari ponsel, karena itu tabel rute harus dibaca langsung.

Beri bridge rute default yang menjadi miliknya

Raspberry Pi OS sering meninggalkan bridge tanpa rute default ketika bridge muncul setelah berkas antarmuka ditulis. Blok itu berada di /etc/dhcpcd.conf, dan harus menyebut router hulu, bukan Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Dalam contoh itu 192.168.50.1 adalah router yang ada dan 192.168.50.2 adalah alamat bridge Pi di subnet yang sama, jadi gantilah dengan rencana Anda sendiri alih-alih menyalin angkanya. Anggota bridge juga tidak boleh meminta router, atau Pi akan berakhir dengan default yang bersaing yang pemenangnya bergantung pada metrik dan waktu, bukan pada niat.

Setelah systemctl restart dhcpcd, ip route show default harus mencantumkan br0 satu kali dan tidak ada duplikat dari porta kabel. Pastikan pencariannya, bukan tabelnya, karena entri lama bisa duduk di samping entri pemenang: ip -4 route get 203.0.113.10 harus menyebut br0. Alamat itu berasal dari rentang dokumentasi TEST-NET-3, jadi tidak bisa bentrok dengan server sungguhan saat Anda membaca ini.

Hentikan tunnel dari membajak jalur ke servernya sendiri

Klien OpenVPN yang menerima redirect-gateway mengambil alih rute default dan mengarahkannya ke dalam tunnel. Itu benar ketika setiap klien titik akses harus memakai VPN, dan salah ketika hanya sebagian tujuan yang harus. Apa pun itu, koneksi Pi sendiri ke server tidak boleh berjalan di dalam tunnel yang masih dibangunnya. OpenVPN menambahkan rute host ke ujung jauh melalui gateway asli ketika mengalihkan default, dan itulah tepatnya perilaku yang menjaga transport tetap hidup; jika rute itu hilang, tunnel runtuh begitu ia terbentuk.

Perbandingan cepat jalur transport itu sebelum dan sesudah menyambung sepadan dengan sepuluh detiknya. ip -4 route get 203.0.113.10 harus menyebut perangkat lapisan bawah di kedua keadaan, hanya metrik yang bergeser. Jika ia menyebut tun0 setelah tunnel naik, rute host tidak pernah dipasang dan koneksi ulang berikutnya akan gagal.

Ketika hanya prefiks terpilih yang boleh melintasi tunnel, gunakan route-nopull dan tambahkan rute yang Anda mau secara manual, atau dorong kumpulan yang lebih sempit dari server. Bridge mempertahankan rute default dalam rancangan itu, dan DNS menjadi keputusan berikutnya: penerusan dnsmasq ke resolver rumah hanya masuk akal untuk nama yang benar-benar tinggal di sana.

Putuskan soal penerusan dan NAT

Tunnel penuh membutuhkan penerusan yang diaktifkan di Pi dan gateway di sisi jauh yang bersedia merutekan subnet titik akses. Periksa penerusan sebelum hal lain, karena nol membuat setiap perubahan rute tidak relevan.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Aturan NAT adalah jalan pintas yang bekerja ketika server tidak akan menerima prefiks titik akses, dengan harga setiap klien tampil sebagai alamat tunnel Pi di log sisi jauh. Merutekan prefiks tanpa NAT menjaga alamat tetap terlihat dan bergantung pada rute balik untuk 192.168.50.0/24 di sisi rumah.

Tuliskan pilihan itu di samping aturan firewall, karena aturan NAT yang tak terlihat dalam rancangan menjadi tak terjelaskan enam bulan kemudian. Pertahankan IPv6 dalam keputusan yang sama; jalur IPv4 yang bekerja di samping jalur IPv6 yang rusak tetap terbaca setengah rusak di peramban.

Verifikasi dari klien, lalu batalkan dengan bersih

Uji dalam urutan ini dari ponsel atau laptop di titik akses: sewa dari dnsmasq, ping ke alamat bridge, lalu tujuan di sisi jauh tunnel. Setiap langkah mengisolasi satu lapisan alih-alih menghasilkan satu kegagalan yang tidak berguna.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Lalu pastikan Pi masih punya jalur keluarnya sendiri: ip route get 203.0.113.10 harus menyebut perangkat lapisan bawah, dan ping -c 3 -I br0 203.0.113.10 harus menjawab jika server mengizinkan ICMP. Jika dua langkah klien pertama lolos dan yang ketiga gagal, kesalahannya ada di penerusan atau NAT. Jika langkah kedua gagal, bridge atau DHCP masih belum lengkap.

Pembatalan adalah satu suntingan berkas dan dua perintah: hapus blok itu, mulai ulang dhcpcd, dan ganti rute default secara eksplisit dengan ip route replace default via 192.168.50.1 dev br0. Lakukan sebelum jendela pemeliharaan ditutup, bukan sesudahnya, karena Pi yang kehilangan rute default-nya tidak dapat dijangkau dari jaringan yang akan Anda pakai untuk memperbaikinya.