hostapd en OpenVPN op een Pi: wie besit die verstekroete?
hostapd en 'n OpenVPN-kliënt kan 'n Pi deel wanneer die brug sy eie verstekroete hou en die tonnel 'n pad na sy bediener behou. Opdragte en terugrol.
Fone assosieer met die toegangspunt, kry 'n adres en bereik dan heeltemal niks sodra die tonnel opkom. hostapd is gewoonlik gesond in daardie toestand, en so ook OpenVPN; wat breek is die verstekroete, wat óf nooit op die brug bestaan het nie óf deur die tonnel vervang is sonder om 'n pad na die VPN-bediener self te laat. Hierdie draaiboek plaas daardie roete terug waar dit hoort en bewys die resultaat van 'n kliënt eerder as van die Pi. Elke stap is omkeerbaar, en niks hier verander die tonnel se konfigurasie voordat jy weet watter verkeer jy binne-in dit wil hê.
Inventariseer die interfaces voordat jy iets wysig
Die bekende uitleg plaas die draadlose radio en die bedrade poort binne br0, begin hostapd teen die brug en deel huurkontrakte uit vanaf dnsmasq, terwyl 'n OpenVPN-kliënt tun0 skep. Drie afsonderlike vereistes lyk dan soos een: toegangspuntkliënte het die Pi as hul poort nodig, die Pi het 'n roete na die internet nodig om sy bediener te bereik, en die brug het 'n poortadres nodig wat daardie kliënte kan gebruik.
Lees die huidige toestand voordat jy dit verander, want hierdie vier opdragte skei 'n interface-probleem van 'n roeteprobleem.
ip -br addr
ip route show
ip link show master br0
bridge link show
As br0 'n adres dra maar geen verstekroete nie, bereik kliënte die Pi en niks verder nie. As die verstekroete na tun0 wys terwyl die tonnel af is, het die Pi glad geen werkende pad nie, en die kliëntsimptoom lyk presies dieselfde. Albei gevalle lyk identies vanaf 'n foon, en daarom moet die roetetabel direk gelees word.
Gee die brug 'n verstekroete wat aan hom behoort
Raspberry Pi OS laat die brug dikwels sonder 'n verstekroete wanneer die brug ontstaan het nadat die interface-lêer geskryf is. Die stanza hoort in /etc/dhcpcd.conf, en dit moet die opstroomroeteerder noem eerder as die 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
In daardie voorbeeld is 192.168.50.1 die bestaande roeteerder en 192.168.50.2 is die Pi se brugadres in dieselfde subnet, so vervang dit met jou eie plan eerder as om die nommers te kopieer. Die bruglede moet nie ook roeteerders aanvra nie, anders eindig die Pi met mededingende verstekke waarvan die wenner van metric en tydsberekening afhang eerder as van bedoeling.
Na systemctl restart dhcpcd moet ip route show default br0 een keer lys en geen duplikaat van die bedrade poort nie. Bevestig die opsoek eerder as die tabel, want 'n verouderde inskrywing kan langs 'n wenende een sit: ip -4 route get 203.0.113.10 moet br0 noem. Daardie adres kom uit die TEST-NET-3-dokumentasiereeks, so dit kan nie met 'n werklike bediener bots terwyl jy dit lees nie.
Stop die tonnel om die pad na sy eie bediener te kaap
'n OpenVPN-kliënt wat redirect-gateway aanvaar, neem die verstekroete oor en wys dit in die tonnel in. Dit is reg wanneer elke toegangspuntkliënt die VPN moet gebruik, en verkeerd wanneer slegs sommige bestemmings dit moet. Hoe dit ook al sy, die Pi se eie verbinding na die bediener mag nie binne die tonnel reis wat hy steeds bou nie. OpenVPN voeg 'n gasheersroete na die afgeleë punt deur die oorspronklike poort by wanneer dit die verstek herlei, en dit is presies die gedrag wat die vervoer lewendig hou; as daardie roete ontbreek, val die tonnel in duie sodra dit vestig.
'n Vinnige vergelyking van daardie vervoerpad voor en na verbinding is die tien sekondes werd. ip -4 route get 203.0.113.10 moet die onderliggende toestel in albei toestande noem, met slegs die metric wat verskuif. As dit tun0 noem nadat die tonnel opkom, is die gasheersroete nooit geïnstalleer nie en sal die volgende herverbinding misluk.
Wanneer slegs geselekteerde voorvoegsels die tonnel moet kruis, gebruik route-nopull en voeg die roetes wat jy wil met die hand by, of stoot 'n smaller stel vanaf die bediener. Die brug behou die verstekroete in daardie ontwerp, en DNS word die volgende besluit: dnsmasq wat na 'n tuisoplosser aanstuur, maak net sin vir die name wat werklik daar woon.
Besluit die aanstuur- en NAT-verhaal
Volle tonnel benodig aanstuur wat op die Pi geaktiveer is en 'n oorkantste poort gewillig om die toegangspunt-subnet te roeteer. Kontroleer aanstuur voor enigiets anders, want 'n nul maak elke roeteverandering irrelevant.
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
Die NAT-reël is die kortpad wat werk wanneer die bediener nie die toegangspunt-voorvoegsel sal aanvaar nie, ten koste daarvan dat elke kliënt as die Pi se tonneladres in oorkantste logboeke verskyn. Roetering van die voorvoegsel sonder NAT hou adresse sigbaar en hang af van 'n terugroete vir 192.168.50.0/24 aan die tuiskant.
Skryf die keuse neer langs die firewall-reëls, want 'n NAT-reël wat onsigbaar in die ontwerp is, word ses maande later onverklaarbaar. Hou IPv6 in dieselfde besluit; 'n werkende IPv4-pad langs 'n gebreekte IPv6-pad lees steeds as halfgebreek in 'n blaaier.
Verifieer vanaf 'n kliënt en rol dan skoon terug
Toets in hierdie volgorde vanaf 'n foon of skootrekenaar op die toegangspunt: 'n huurkontrak van dnsmasq, 'n ping na die brugadres, dan 'n bestemming aan die oorkantste kant van die tonnel. Elke stap isoleer een laag eerder as om 'n enkele onbehulpsame mislukking te lewer.
ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10
Bevestig dan dat die Pi steeds sy eie pad uit het: ip route get 203.0.113.10 moet die onderliggende toestel noem, en ping -c 3 -I br0 203.0.113.10 moet antwoord as die bediener ICMP toelaat. As die eerste twee kliëntstappe slaag en die derde misluk, sit die fout in aanstuur of NAT. As die tweede stap misluk, is die brug of DHCP steeds onvolledig.
Terugrol is een lêerwysiging en twee opdragte: verwyder die stanza, herbegin dhcpcd en vervang die verstekroete uitdruklik met ip route replace default via 192.168.50.1 dev br0. Doen dit voordat die onderhoudsvenster sluit eerder as daarna, want 'n Pi wat sy verstekroete verloor het, is onbereikbaar vanaf die netwerk wat jy sou gebruik om dit te herstel.