hostapd kaj OpenVPN sur unu Pi: kiu posedas la defaŭltan itineron?

Telefonoj konektiĝas al la alirpunkto, ricevas adreson kaj poste atingas nenion, tuj kiam la tunelo leviĝas. hostapd estas kutime sana en tiu stato, kaj same OpenVPN; tio, kio rompiĝas, estas la defaŭlta itinero, kiu aŭ neniam ekzistis sur la ponto aŭ estis anstataŭigita de la tunelo sen lasi vojon al la VPN-servilo mem. Ĉi tiu manlibro metas tiun itineron reen, kie ĝi apartenas, kaj pruvas la rezulton de kliento anstataŭ de la Pi. Ĉiu paŝo estas malfarebla, kaj nenio ĉi tie ŝanĝas la agordon de la tunelo ĝis vi scios, kiun trafikon vi volas ene de ĝi.

Inventaru la interfacojn antaŭ ol vi redakti ion ajn

La kutima aranĝo metas la sendratan radion kaj la kablan pordon ene de br0, startigas hostapd kontraŭ la ponto kaj disdonas luojn el dnsmasq, dum OpenVPN-kliento kreas tun0. Tiam tri apartaj postuloj aspektas kiel unu: klientoj de la alirpunkto bezonas la Pi kiel sian enirejon, la Pi bezonas itineron al la interreto por atingi sian servilon, kaj la ponto bezonas enirejan adreson, kiun tiuj klientoj povas uzi.

Legi la nunan staton antaŭ ol ŝanĝi ĝin, ĉar ĉi tiuj kvar komandoj apartigas interfacan problemon de itinera problemo.

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

Se br0 portas adreson sed neniun defaŭltan itineron, klientoj atingas la Pi kaj nenion preter ĝi. Se la defaŭlta itinero montras al tun0 dum la tunelo estas malsupre, la Pi tute ne havas funkciantan vojon, kaj la simptomo de la kliento aspektas ĝuste same. Ambaŭ kazoj aspektas idente de telefono, tial la itinera tabelo devas esti legata rekte.

Donu al la ponto defaŭltan itineron, kiu apartenas al ĝi

Raspberry Pi OS ofte lasas la ponton sen defaŭlta itinero, kiam la ponto ekestis post kiam la interfaca dosiero estis skribita. La bloko apartenas en /etc/dhcpcd.conf, kaj ĝi devus nomi la supran enkursigilon anstataŭ la 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

En tiu ekzemplo 192.168.50.1 estas la ekzistanta enkursigilo kaj 192.168.50.2 estas la ponta adreso de la Pi en la sama subreto, do anstataŭigu per via propra plano anstataŭ kopii la nombrojn. La pontaj membroj ankaŭ ne rajtas peti enkursigilojn, alie la Pi finos kun konkurantaj defaŭltoj, kies venkinto dependas de metriko kaj tempo anstataŭ de intenco.

Post systemctl restart dhcpcd ip route show default devus listigi br0 unufoje kaj neniun duplikaton de la kabila pordo. Konfirmu la serĉon anstataŭ la tabelon, ĉar malnova rikordo povas sidi apud venka: ip -4 route get 203.0.113.10 devas nomi br0. Tiu adreso venas el la dokumenta gamo TEST-NET-3, do ĝi ne povas kolizii kun reala servilo dum vi legas ĉi tion.

Malhelpu la tunelon kaperi la vojon al sia propra servilo

OpenVPN-kliento, kiu akceptas redirect-gateway, transprenas la defaŭltan itineron kaj direktas ĝin en la tunelon. Tio pravas, kiam ĉiu alirpunkta kliento devus uzi la VPN, kaj malpravas, kiam nur kelkaj cellokoj devus. Ĉiel ajn, la propra konekto de la Pi al la servilo ne rajtas vojaĝi ene de la tunelo, kiun ĝi ankoraŭ konstruas. OpenVPN aldonas gastigan itineron al la foraĵo tra la origina enirejo, kiam ĝi alidirektas la defaŭlton, kaj tio estas ĝuste la konduto, kiu tenas la transporton viva; se tiu itinero mankas, la tunelo kolapsas tuj kiam ĝi establiĝas.

Rapida komparo de tiu transporta vojo antaŭ kaj post konekto valoras la dek sekundojn. ip -4 route get 203.0.113.10 devus nomi la suban aparaton en ambaŭ statoj, nur la metriko ŝanĝiĝas. Se ĝi nomas tun0 post kiam la tunelo leviĝas, la gastiga itinero neniam estis instalita kaj la sekva rekonekto malsukcesos.

Kiam nur elektitaj prefiksoj devus transiri la tunelon, uzu route-nopull kaj aldonu la itinerojn, kiujn vi volas, permane, aŭ puŝu pli mallarĝan aron el la servilo. La ponto konservas la defaŭltan itineron en tiu dezajno, kaj DNS fariĝas la sekva decido: plusendado de dnsmasq al hejma solvilo havas sencon nur por la nomoj, kiuj vere loĝas tie.

Decidu la rakonton de plusendado kaj NAT

Plena tunelo bezonas plusendadon ebligitan sur la Pi kaj enirejon en la malproksima flanko preta itinerigi la subreton de la alirpunkto. Kontrolu plusendadon antaŭ ĉio alia, ĉar nulo igas ĉiun itineroŝanĝon sensignifa.

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

La NAT-regulo estas la mallongigo, kiu funkcias, kiam la servilo ne akceptos la prefikson de la alirpunkto, je la kosto, ke ĉiu kliento aperas kiel la tunela adreso de la Pi en la protokoloj de la malproksima flanko. Itinerigi la prefikson sen NAT konservas la adresojn videblaj kaj dependas de revena itinero por 192.168.50.0/24 en la hejma flanko.

Skribu la elekton apud la fajroŝirmilaj reguloj, ĉar NAT-regulo nevidebla en la dezajno fariĝas neklarigebla post ses monatoj. Tenu IPv6 en la sama decido; funkcianta IPv4-vojo apud rompita IPv6-vojo ankoraŭ legiĝas kiel duone rompita en retumilo.

Kontrolu de kliento, poste malfaru pure

Testu en ĉi tiu ordo de telefono aŭ tekkomputilo sur la alirpunkto: luo el dnsmasq, ping al la ponta adreso, poste celloko en la malproksima flanko de la tunelo. Ĉiu paŝo izolas unu tavolon anstataŭ produkti unu senutilan malsukceson.

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

Poste konfirmu, ke la Pi ankoraŭ havas sian propran eliron: ip route get 203.0.113.10 devus nomi la suban aparaton, kaj ping -c 3 -I br0 203.0.113.10 devus respondi, se la servilo permesas ICMP. Se la unuaj du klientaj paŝoj pasas kaj la tria malsukcesas, la kulpo estas en plusendado aŭ NAT. Se la dua paŝo malsukcesas, la ponto aŭ DHCP ankoraŭ nekompletas.

Malfaro estas unu dosiera redakto kaj du komandoj: forigu la blokon, restartigu dhcpcd kaj anstataŭigu la defaŭltan itineron eksplicite per ip route replace default via 192.168.50.1 dev br0. Faru tion antaŭ ol fermiĝos la prizorga fenestro, ne poste, ĉar Pi, kiu perdis sian defaŭltan itineron, estas neatingebla el la reto, kiun vi uzus por ripari ĝin.