hostapd dan OpenVPN pada satu Pi: siapa pemilik laluan lalai?

Telefon menyambung ke titik akses, menerima alamat, kemudian tidak sampai ke apa-apa sebaik terowong naik. hostapd biasanya sihat dalam keadaan itu, dan OpenVPN juga; yang rosak ialah laluan lalai, yang sama ada tidak pernah wujud pada jambatan atau digantikan oleh terowong tanpa meninggalkan laluan ke pelayan VPN itu sendiri. Panduan ini mengembalikan laluan itu ke tempatnya dan membuktikan hasilnya dari klien, bukan dari Pi. Setiap langkah boleh dibalikkan, dan tiada apa di sini mengubah konfigurasi terowong sehingga anda tahu trafik apa yang anda mahu di dalamnya.

Senaraikan antara muka sebelum anda mengedit apa-apa

Susun atur biasa meletakkan radio wayarles dan port berwayar di dalam br0, memulakan hostapd terhadap jambatan dan mengagihkan pajakan dari dnsmasq, sementara klien OpenVPN mencipta tun0. Kemudian tiga keperluan berasingan kelihatan seperti satu: klien titik akses memerlukan Pi sebagai get laluan mereka, Pi memerlukan laluan ke internet untuk mencapai pelayannya, dan jambatan memerlukan alamat get laluan yang boleh digunakan oleh klien itu.

Baca keadaan semasa sebelum mengubahnya, kerana empat arahan ini memisahkan masalah antara muka daripada masalah penghalaan.

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

Jika br0 membawa alamat tetapi tiada laluan lalai, klien sampai ke Pi dan tiada apa di luarnya. Jika laluan lalai menunjuk ke tun0 semasa terowong turun, Pi tidak mempunyai laluan yang berfungsi langsung, dan gejala klien kelihatan sama. Kedua-dua kes kelihatan serupa dari telefon, sebab itu jadual laluan mesti dibaca terus.

Beri jambatan laluan lalai yang menjadi miliknya

Raspberry Pi OS sering membiarkan jambatan tanpa laluan lalai apabila jambatan wujud selepas fail antara muka ditulis. Blok itu tergolong dalam /etc/dhcpcd.conf, dan ia harus menamakan penghala huluan dan 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 ialah penghala sedia ada dan 192.168.50.2 ialah alamat jambatan Pi dalam subnet yang sama, jadi gantikan dengan pelan anda sendiri dan bukan menyalin nombor itu. Ahli jambatan juga tidak boleh meminta penghala, jika tidak Pi berakhir dengan laluan lalai yang bersaing yang pemenangnya bergantung pada metrik dan masa, bukan pada niat.

Selepas systemctl restart dhcpcd, ip route show default harus menyenaraikan br0 sekali dan tiada pendua daripada port berwayar. Sahkan carian dan bukan jadual, kerana entri lama boleh duduk di sebelah entri pemenang: ip -4 route get 203.0.113.10 mesti menamakan br0. Alamat itu datang dari julat dokumentasi TEST-NET-3, jadi ia tidak boleh bertembung dengan pelayan sebenar semasa anda membaca ini.

Hentikan terowong daripada merampas laluan ke pelayannya sendiri

Klien OpenVPN yang menerima redirect-gateway mengambil alih laluan lalai dan menghalakannya ke dalam terowong. Itu betul apabila setiap klien titik akses patut menggunakan VPN, dan salah apabila hanya sebahagian destinasi patut. Walau apa pun, sambungan Pi sendiri ke pelayan tidak boleh melalui dalam terowong yang masih dibinanya. OpenVPN menambah laluan hos ke hujung jauh melalui get laluan asal apabila ia mengubah hala laluan lalai, dan itulah tingkah laku yang mengekalkan pengangkutan hidup; jika laluan itu tiada, terowong runtuh sebaik sahaja ia terbentuk.

Perbandingan pantas laluan pengangkutan itu sebelum dan selepas menyambung berbaloi dengan sepuluh saat itu. ip -4 route get 203.0.113.10 harus menamakan peranti lapisan bawah dalam kedua-dua keadaan, hanya metrik berubah. Jika ia menamakan tun0 selepas terowong naik, laluan hos tidak pernah dipasang dan sambungan semula seterusnya akan gagal.

Apabila hanya awalan terpilih patut melintasi terowong, gunakan route-nopull dan tambah laluan yang anda mahu secara manual, atau tolak set yang lebih sempit dari pelayan. Jambatan mengekalkan laluan lalai dalam reka bentuk itu, dan DNS menjadi keputusan seterusnya: pemajuan dnsmasq ke penyelesai rumah hanya masuk akal untuk nama yang benar-benar tinggal di sana.

Putuskan hal pemajuan dan NAT

Terowong penuh memerlukan pemajuan diaktifkan pada Pi dan get laluan di sebelah jauh yang bersedia menghalakan subnet titik akses. Periksa pemajuan sebelum apa-apa lagi, kerana sifar menjadikan setiap perubahan laluan 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

Peraturan NAT ialah jalan pintas yang berfungsi apabila pelayan tidak menerima awalan titik akses, dengan kos setiap klien kelihatan sebagai alamat terowong Pi dalam log sebelah jauh. Menghalakan awalan tanpa NAT mengekalkan alamat kelihatan dan bergantung pada laluan balik untuk 192.168.50.0/24 di sebelah rumah.

Tuliskan pilihan itu di sebelah peraturan tembok api, kerana peraturan NAT yang tidak kelihatan dalam reka bentuk menjadi tidak dapat dijelaskan enam bulan kemudian. Kekalkan IPv6 dalam keputusan yang sama; laluan IPv4 yang berfungsi di sebelah laluan IPv6 yang rosak masih dibaca sebagai separuh rosak dalam pelayar.

Sahkan dari klien, kemudian balikkan dengan bersih

Uji dalam urutan ini dari telefon atau komputer riba di titik akses: pajakan dari dnsmasq, ping ke alamat jambatan, kemudian destinasi di sebelah jauh terowong. Setiap langkah mengasingkan satu lapisan dan bukannya menghasilkan satu kegagalan yang tidak berguna.

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

Kemudian sahkan Pi masih mempunyai laluan keluarnya sendiri: ip route get 203.0.113.10 harus menamakan peranti lapisan bawah, dan ping -c 3 -I br0 203.0.113.10 harus menjawab jika pelayan membenarkan ICMP. Jika dua langkah klien pertama lulus dan yang ketiga gagal, kesalahan terletak pada pemajuan atau NAT. Jika langkah kedua gagal, jambatan atau DHCP masih belum lengkap.

Pembalikan ialah satu suntingan fail dan dua arahan: buang blok itu, mulakan semula dhcpcd, dan ganti laluan lalai secara eksplisit dengan ip route replace default via 192.168.50.1 dev br0. Lakukan sebelum tetingkap penyelenggaraan ditutup dan bukan selepasnya, kerana Pi yang kehilangan laluan lalainya tidak dapat dicapai dari rangkaian yang anda akan gunakan untuk membaikinya.