hostapd na OpenVPN kwenye Pi moja: njia chaguo-msingi ni ya nani?
hostapd na mteja wa OpenVPN wanaweza kushiriki Pi moja wakati daraja linahifadhi njia yake chaguo-msingi na handaki linahifadhi njia kuelekea seva yake. Amri na kurudisha nyuma.
Simu zinaunganishwa na kituo cha ufikiaji, zinapata anwani, kisha hazifiki chochote mara handaki linapoinuka. hostapd kwa kawaida huwa mzima katika hali hiyo, na OpenVPN pia; kinachovunjika ni njia chaguo-msingi, ambayo ama haikuwahi kuwepo kwenye daraja au handaki liliibadilisha bila kuacha njia kuelekea seva ya VPN yenyewe. Mwongozo huu unarudisha njia hiyo mahali pake na kuthibitisha matokeo kutoka kwa mteja na si kutoka kwa Pi. Kila hatua inaweza kurudishwa nyuma, na hakuna chochote hapa kinachobadilisha usanidi wa handaki hadi ujue ni trafiki gani unataka ndani yake.
Orodhesha violesura kabla ya kuhariri chochote
Mpangilio unaojulikana unaweka redio isiyo na waya na mlango wa waya ndani ya br0, huanzisha hostapd dhidi ya daraja na kugawa ukodishaji kutoka dnsmasq, huku mteja wa OpenVPN akiunda tun0. Kisha mahitaji matatu tofauti yanaonekana kama moja: wateja wa kituo cha ufikiaji wanahitaji Pi kama lango lao, Pi inahitaji njia ya kufikia intaneti ili kufikia seva yake, na daraja linahitaji anwani ya lango ambayo wateja hao wanaweza kutumia.
Soma hali ya sasa kabla ya kuibadilisha, kwa sababu amri hizi nne hutenganisha tatizo la violesura na tatizo la uelekezaji.
ip -br addr
ip route show
ip link show master br0
bridge link show
Ikiwa br0 ina anwani lakini haina njia chaguo-msingi, wateja wanafikia Pi na hakuna kingine zaidi yake. Ikiwa njia chaguo-msingi inaelekeza kwenye tun0 wakati handaki liko chini, Pi haina njia inayofanya kazi kabisa, na dalili ya mteja inaonekana sawa kabisa. Kesi zote mbili zinaonekana sawa kutoka kwa simu, ndiyo sababu jedwali la njia linapaswa kusomwa moja kwa moja.
Ipe daraja njia chaguo-msingi inayomilikiwa nalo
Raspberry Pi OS mara nyingi huacha daraja bila njia chaguo-msingi wakati daraja liliundwa baada ya faili ya violesura kuandikwa. Kizuizi hicho ni cha /etc/dhcpcd.conf, na kinapaswa kutaja kipanga njia cha juu na si 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
Katika mfano huo 192.168.50.1 ni kipanga njia kilichopo na 192.168.50.2 ni anwani ya daraja la Pi katika subnet hiyo hiyo, kwa hivyo weka mpango wako mwenyewe badala ya kunakili namba. Wanachama wa daraja pia hawapaswi kuomba vipanga njia, vinginevyo Pi itabaki na njia chaguo-msingi zinazoshindana ambazo mshindi wake hutegemea metriki na muda na si nia.
Baada ya systemctl restart dhcpcd ip route show default inapaswa kuorodhesha br0 mara moja na hakuna nakala kutoka kwa mlango wa waya. Thibitisha utafutaji na si jedwali, kwa sababu ingizo la zamani linaweza kukaa kando ya linaloshinda: ip -4 route get 203.0.113.10 lazima litaje br0. Anwani hiyo inatoka katika safu ya nyaraka ya TEST-NET-3, kwa hivyo haiwezi kugongana na seva halisi unaposoma hii.
Zuia handaki lisije likaiba njia kuelekea seva yake mwenyewe
Mteja wa OpenVPN anayekubali redirect-gateway anachukua njia chaguo-msingi na kuielekeza ndani ya handaki. Hiyo ni sahihi wakati kila mteja wa kituo cha ufikiaji anapaswa kutumia VPN, na si sahihi wakati ni baadhi ya mahali tu panapopaswa. Kwa vyovyote vile, muunganisho wa Pi wenyewe kwa seva haupaswi kusafiri ndani ya handaki ambalo bado analijenga. OpenVPN huongeza njia ya mwenyeji kuelekea upande wa mbali kupitia lango la awali linapoelekeza upya njia chaguo-msingi, na hiyo ndiyo tabia inayoufanya usafirishaji uendelee kuwa hai; ikiwa njia hiyo haipo, handaki huanguka mara linapojitokeza.
Ulinganisho wa haraka wa njia hiyo ya usafirishaji kabla na baada ya kuunganisha unastahili sekunde hizo kumi. ip -4 route get 203.0.113.10 inapaswa kutaja kifaa cha tabaka la chini katika hali zote mbili, kinachobadilika ni metriki pekee. Ikiwa inataja tun0 baada ya handaki kupanda, njia ya mwenyeji haikuwekwa kamwe na muunganisho unaofuata utashindikana.
Wakati ni viambishi vilivyochaguliwa pekee vinapaswa kuvuka handaki, tumia route-nopull na uongeze njia unazotaka kwa mkono, au tuma seti nyembamba kutoka kwa seva. Daraja linahifadhi njia chaguo-msingi katika muundo huo, na DNS inakuwa uamuzi unaofuata: kuelekeza dnsmasq kwa kitatuzi cha nyumbani kunaleta maana kwa majina yanayoishi hapo kweli.
Amua kuhusu uelekezaji na NAT
Handaki kamili linahitaji uelekezaji umewezeshwa kwenye Pi na lango upande wa mbali lililo tayari kuelekeza subnet ya kituo cha ufikiaji. Angalia uelekezaji kabla ya kitu kingine chochote, kwa sababu sifuri hufanya kila mabadiliko ya njia kuwa yasiyohusika.
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
Kanuni ya NAT ni njia ya mkato inayofanya kazi wakati seva haitakubali kiambishi cha kituo cha ufikiaji, kwa gharama ya kila mteja kuonekana kama anwani ya handaki ya Pi kwenye kumbukumbu za upande wa mbali. Kuelekeza kiambishi bila NAT huweka anwani zionekane na inategemea njia ya kurudi kwa 192.168.50.0/24 upande wa nyumbani.
Andika chaguo kando ya kanuni za firewall, kwa sababu kanuni ya NAT isiyoonekana katika muundo huwa isiyoelezeka baada ya miezi sita. Weka IPv6 katika uamuzi huo huo; njia ya IPv4 inayofanya kazi kando ya njia ya IPv6 iliyovunjika bado inasomwa kama nusu iliyovunjika kwenye kivinjari.
Thibitisha kutoka kwa mteja, kisha rudisha nyuma kwa usafi
Jaribu kwa mpangilio huu kutoka kwa simu au laptop kwenye kituo cha ufikiaji: ukodishaji kutoka dnsmasq, ping kwa anwani ya daraja, kisha mahali upande wa mbali wa handaki. Kila hatua hutenganisha tabaka moja badala ya kutoa kushindikana moja kusiyo na maana.
ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10
Kisha thibitisha kwamba Pi bado ina njia yake ya kutoka: ip route get 203.0.113.10 inapaswa kutaja kifaa cha tabaka la chini, na ping -c 3 -I br0 203.0.113.10 inapaswa kujibu ikiwa seva inaruhusu ICMP. Ikiwa hatua mbili za kwanza za mteja zinapita na ya tatu inashindikana, hitilafu iko kwenye uelekezaji au NAT. Ikiwa hatua ya pili inashindikana, daraja au DHCP bado hazijakamilika.
Kurudisha nyuma ni uhariri mmoja wa faili na amri mbili: ondoa kizuizi, anzisha upya dhcpcd, na ubadilishe njia chaguo-msingi waziwazi na ip route replace default via 192.168.50.1 dev br0. Fanya hivyo kabla dirisha la matengenezo halijafungwa na si baadaye, kwa sababu Pi iliyopoteza njia yake chaguo-msingi haifikiki kutoka kwenye mtandao ambao ungetumia kuirekebisha.