hostapd og OpenVPN á einni Pi: hver á sjálfgefnu leiðina?

Símar tengjast aðgangsstaðnum, fá tölu og ná síðan engu þegar göngin koma upp. hostapd er venjulega heilbrigt í því ástandi, og OpenVPN líka; það sem brotnar er sjálfgefna leiðin, sem annaðhvort var aldrei til á brúnni eða göngin skiptu henni út án þess að skilja eftir leið að VPN-þjóninum sjálfum. Þessi handbók setur þá leið aftur á sinn stað og sannar niðurstöðuna frá biðlara frekar en frá Pi. Hvert skref er afturkræft, og ekkert hér breytir stillingum ganganna fyrr en þú veist hvaða umferð þú vilt inni í þeim.

Gerðu lista yfir viðmótin áður en þú breytir nokkru

Hefðbundin uppsetning setur þráðlausa útvarpið og snúruportið inni í br0, ræsir hostapd gegn brúnni og úthlutar leigum frá dnsmasq, á meðan OpenVPN-biðlari býr til tun0. Þá líta þrjár aðskildar kröfur út eins og ein: biðlarar aðgangsstaðarins þurfa Pi sem gátt, Pi þarf leið út á internetið til að ná þjóninum sínum, og brúin þarf gáttartölu sem þessir biðlarar geta notað.

Lestu núverandi ástand áður en þú breytir því, því þessar fjórar skipanir aðgreina viðmótsvandamál frá leiðavandamáli.

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

Ef br0 ber tölu en enga sjálfgefna leið ná biðlarar til Pi og einskis handan við hana. Ef sjálfgefna leiðin bendir á tun0 meðan göngin eru niðri hefur Pi enga virka leið yfirhöfuð, og einkennin hjá biðlaranum líta nákvæmlega eins út. Bæði tilvikin líta eins út frá síma, þess vegna verður að lesa leiðatöfluna beint.

Gefðu brúnni sjálfgefna leið sem tilheyrir henni

Raspberry Pi OS skilur brúna oft eftir án sjálfgefinnar leiðar þegar brúin varð til eftir að viðmótskráin var skrifuð. Blokkin á heima í /etc/dhcpcd.conf, og hún ætti að nefna routerinn ofar, ekki 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

Í því dæmi er 192.168.50.1 núverandi router og 192.168.50.2 er brúartala Pi í sama undirneti, svo settu þína eigin áætlun í staðinn í stað þess að afrita tölurnar. Meðlimir brúarinnar mega heldur ekki biðja um routera, annars endar Pi með samkeppnis sjálfgefnar leiðir þar sem sigurvegarinn fer eftir mælikvarða og tímasetningu frekar en ásetningi.

Eftir systemctl restart dhcpcd ætti ip route show default að lista br0 einu sinni og enga tvítekningu frá snúruportinu. Staðfestu uppflettinguna frekar en töfluna, því gömul færsla getur setið við hlið sigrandi færslu: ip -4 route get 203.0.113.10 verður að nefna br0. Þessi tala kemur úr skjölunarsviðinu TEST-NET-3, svo hún getur ekki rekist á raunverulegan þjón á meðan þú lest þetta.

Komið í veg fyrir að göngin ræni leiðinni að þjóninum sínum

OpenVPN-biðlari sem samþykkir redirect-gateway tekur yfir sjálfgefnu leiðina og beinir henni inn í göngin. Það er rétt þegar hver biðlari aðgangsstaðarins ætti að nota VPN og rangt þegar aðeins sumir áfangastaðir ættu það. Hvort sem er, má tenging Pi sjálfrar við þjóninn ekki ferðast inni í göngunum sem hún er enn að byggja. OpenVPN bætir við hýsil-leið að fjartengda endanum um upprunalegu gáttina þegar það beinir sjálfgefnu leiðinni á ný, og það er einmitt sú hegðun sem heldur flutningnum lifandi; ef þessi leið vantar, hrynja göngin um leið og þau koma sér fyrir.

Skjótur samanburður á þeirri flutningsleið fyrir og eftir tengingu er þess virði sem tekur tíu sekúndur. ip -4 route get 203.0.113.10 ætti að nefna tækið undir í báðum stöðum, aðeins mælikvarðinn færist. Ef það nefnir tun0 eftir að göngin koma upp var hýsilleiðin aldrei sett upp og næsta endurtenging mistekst.

Þegar aðeins valin forskeyti eiga að fara í gegnum göngin, notaðu route-nopull og bættu við leiðunum sem þú vilt handvirkt, eða ýttu þrengra setti frá þjóninum. Brúin heldur sjálfgefnu leiðinni í þeirri hönnun, og DNS verður næsta ákvörðun: framsending dnsmasq til heimalausnar hefur aðeins merkingu fyrir nöfnin sem raunverulega búa þar.

Ákveddu málið um framsendingu og NAT

Full göng krefjast virkrar framsendingar á Pi og gáttar hinum megin sem er reiðubúin að leiða undirnet aðgangsstaðarins. Athugaðu framsendinguna fyrir allt annað, því núll gerir hverja leiðabreytingu ómerkilega.

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

NAT-reglan er flýtileiðin sem virkar þegar þjónninn samþykkir ekki forskeyti aðgangsstaðarins, á þeim kostnaði að hver biðlari birtist sem göngutala Pi í annálum hins megin. Að leiða forskeytið án NAT heldur tölunum sýnilegum og fer eftir afturleið fyrir 192.168.50.0/24 heima.

Skrifaðu valið við hlið eldveggjarreglnanna, því NAT-regla sem er ósýnileg í hönnuninni verður óútskýranleg eftir sex mánuði. Hafðu IPv6 í sömu ákvörðun; virk IPv4-leið við hlið brostinnar IPv6-leiðar lesst enn sem hálf brostin í vafra.

Sannprófaðu frá biðlara og farðu svo hreint til baka

Prófaðu í þessari röð frá síma eða fartölvu á aðgangsstaðnum: leiga frá dnsmasq, ping á brúartöluna, síðan áfangastaður hinum megin í göngunum. Hvert skref einangrar eitt lag í stað þess að framleiða eina gagnslausa bilun.

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

Staðfestu svo að Pi hafi enn sína eigin leið út: ip route get 203.0.113.10 ætti að nefna tækið undir, og ping -c 3 -I br0 203.0.113.10 ætti að svara ef þjónninn leyfir ICMP. Ef fyrstu tvö skref biðlarans standast og þriðja mistekst liggur gallinn í framsendingunni eða NAT. Ef annað skrefið mistekst eru brúin eða DHCP enn ófullkomin.

Afturköllun er ein skráabreyting og tvær skipanir: fjarlægðu blokkina, endurræstu dhcpcd og skiptu sjálfgefnu leiðinni út með ip route replace default via 192.168.50.1 dev br0. Gerðu það áður en viðhaldsgluggann lokar frekar en eftir, því Pi sem hefur misst sjálfgefnu leiðina sína er óaðgengileg frá netinu sem þú myndir nota til að laga hana.