Wateja wa hotspot kwenye Pi hawafikii LAN ya nyumbani kupitia TUN VPN

Wateja wa ndani wa Wi-Fi na Ethernet wanaunganisha na hotspot ya Pi, wanachukua anwani kutoka safu yake ya DHCP na kupakia kurasa za mtandao bila malalamiko. Wateja hao hao baadaye wanapata muda umeisha wanapofungua ushirikiano wa faili au kiolesura cha wavuti kwenye LAN ya nyumbani, wakati Pi yenyewe inafikia LAN hiyo kupitia handaki. Hakuna kilichovunjika katika tabaka la waya. Kinachokosekana ni mkataba ulioelekezwa: kiambishi awali cha hotspot lazima kibebwe ndani ya kiolesura cha TUN, na kitu upande wa nyumbani lazima kijue jinsi ya kutuma majibu huko nyuma. Nusu zote mbili lazima ziwepo kabla pakiti moja haijakamilisha safari ya kwenda na kurudi.

Viungo vitatu vyenye kazi tatu tofauti

Daraja la Ethernet la Linux husambaza fremu kwa anwani ya MAC ya lengo. OpenVPN katika hali ya TUN hubeba pakiti za IP na haina tabaka la MAC kabisa, kwa hivyo kuongeza daraja la ndani hakuwahi kusajili handaki kama bandari. nyaraka za kerneli za TUN/TAP zinaeleza mgawanyiko huo: kifaa cha TAP kinaonekana kama kiolesura cha Ethernet, kifaa cha TUN hakionekani hivyo. Muundo unaounganisha bandari mbili za ndani kisha kuelekeza ni kipanga njia, vyovyote vinavyosema majina ya violesura.

Tofauti hiyo huamua umiliki. Subneti ya wateja, lango lao la msingi na mamlaka ya DHCP kwa safu hiyo ni za mpango wa ndani wa Pi. Matangazo ya DHCP ya nyumbani hayavuki handaki iliyoelekezwa, na hakuna mpangilio wa daraja unaobadilisha hilo; kuwaelekeza wateja kwa seva ya DHCP ya nyumbani ni muundo wa relay tofauti na wa kukusudia wenye hali zake za kushindwa.

Weka modem nje ya daraja la wateja pia. Muunganisho wa PPP si kifaa cha Ethernet chenye lebo nyingine, na mantiki iliyoandikwa ya njia ya msingi ya pppd hufanya kazi baada ya mazungumzo ya IPCP na kuondoa njia yake wakati kiungo hicho kinapoanguka. Kunakili kiolezo cha DHCP na kubadilisha jina la kila usb0 kuwa ppp0 hakuthibitishi chochote kuhusu lango, kipimo au mzunguko wa maisha.

Chagua viambishi awali kabla ya kuhariri usanidi wowote

Viambishi awali vinavyopishana hutumia jioni nyingi zaidi kuliko kanuni za firewall, kwa sababu mwingiliano hutuma utafutaji wa njia kwa kiolesura kisicho sahihi hata handaki ikiwa nzima. Anza kwa kuorodhesha kilichopo tayari kwenye Pi, kisha soma matokeo kama mabwawa manne tofauti.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Bwawa la kwanza ni anwani ya underlay ambayo mtoa huduma alimpa modem; lazima ibaki nje ya mpango wowote unaoelekea wateja. La pili ni subneti ya handaki iliyochaguliwa na seva, mara nyingi /24 yake ya kibinafsi. La tatu ni daraja la hotspot, na la nne ni kiambishi awali cha nyumbani unachotaka kufikia. Katika mwendo huu hotspot inapata 172.28.90.0/24 huku daraja likiwa kwenye 172.28.90.1, na LAN ya huduma za nyumbani inabaki na 192.168.77.0/24, jambo ambalo linaepuka chaguo-msingi 192.168.1.0/24 na 10.0.0.0/24 zinazoletwa na vipanga njia vya watumiaji na safu ya mtoa huduma 100.64.0.0/10.

Tangaza anwani ya daraja kama lango katika safu ya DHCP ya hotspot na kitu kingine chochote. Kamwe usiwape wateja wa hotspot anwani ya nyumbani kama lango; hawana njia ya tabaka la kiungo kuelekea sehemu hiyo.

Elekeza kila mwelekeo upande unaomiliki

Pi inahitaji njia ya kiambishi awali cha nyumbani kupitia handaki. Seva katika hali ya seva kwa kawaida husukuma njia hiyo, kwa hivyo kwanza thibitisha kwamba uelekezaji umewashwa na kwamba kerneli hutatua anwani ya nyumbani kutoka tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Ikiwa ip route get bado inaripoti kiolesura cha underlay, simama hapo; hakuna kingine mbele kwenye njia kinachoweza kurekebisha utafutaji mbaya.

Vifaa vya nyumbani havina njia kuelekea 172.28.90.0/24, kwa hivyo majibu yao hufuata lango la msingi na kufa kwenye kipanga njia. Kuna marekebisho mawili yanayoungwa mkono. Ama ongeza njia tuli kwenye kipanga njia cha nyumbani inayoelekeza kiambishi awali cha hotspot kwa anwani ya LAN ya seva ya VPN, au, seva ikiwa yenyewe ni lango, sajili kiambishi awali cha mteja katika jedwali la uelekezaji la seva yenyewe. Katika hali ya wateja wengi ya OpenVPN, saraka maalum ya mteja hubeba uhusiano huo: faili lililopewa jina la jina la kawaida la cheti cha mteja, lenye iroute 172.28.90.0 255.255.255.0 pamoja na mstari unaolingana wa route unaoisakinisha kwenye kerneli ya seva. Njia ya kerneli iliyokisiwa kwenye seva si kauli sawa na kumwambia seva ni mteja gani anamiliki kiambishi awali.

Usihamishe huduma ya DHCP ya mtandao wa nyumbani kwenda kwa seva ya VPN ili hii ifanye kazi. Kubadilisha lango la msingi kwa nyumba nzima ni mabadiliko makubwa zaidi kuliko kuongeza njia moja ya kurudi ya kibinafsi, na huvuta DNS, uhifadhi wa anwani na kila kifaa kinachopuuza ukodishaji mpya kwenye kushindwa.

Fungua uelekezaji bila kukisia firewall

Uelekezaji umewashwa haimaanishi pakiti inaruhusiwa kupita. Trafiki kutoka daraja kwenda handaki bado inagonga kanuni za kuchuja, na sera ya msingi ya uelekezaji drop hutupa trafiki ya hotspot wakati trafiki ya Pi yenyewe inaendelea kufanya kazi, jambo ambalo huzalisha hasa dalili iliyogawanyika juu.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Tafuta kanuni ya kukubali kutoka br0 hadi tun0 na mwelekeo wa jibu unaolingana, na kanuni ya postrouting inayoweza kuandika upya chanzo. Ikiwa sera ya mnyororo ni drop na hakuna kanuni inayolingana, ongeza kukubali nyembamba na ujaribu tena badala ya kugeuza sera kuwa accept.

Tafsiri ni chaguo la sera, si hitaji. NAT ya chanzo kuelekea LAN ya nyumbani hufanya kila mteja wa hotspot aonekane kama anwani ya handaki ya Pi, jambo ambalo hupoteza ugawaji kwa kila mteja kwenye kumbukumbu za nyumbani na huvunja huduma zinazotarajia chanzo asilia. Uelekezaji bila NAT huweka anwani za wateja zionekane lakini hutegemea njia ya kurudi juu. Chagua moja na shughulikia DNS na IPv6 vivyo hivyo, kwa sababu njia ya IPv4 inayofanya kazi kando ya njia ya IPv6 iliyovunjika bado inasomwa kama nusu iliyovunjika kwenye kivinjari.

Thibitisha safari ya kwenda na kurudi, kisha ivunje kwa makusudi

Jaribu kutoka kwa mteja wa hotspot, kamwe usijaribu kutoka Pi, kwa sababu trafiki ya Pi yenyewe hupita njia ya mbele na ya kurudi. Tazama violesura vyote viwili wakati mteja mmoja anajaribu kufikia huduma ya nyumbani.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Soma rekodi mbili pamoja. Maombi kwenye br0 ambayo hayatokei kamwe kwenye tun0 yanamaanisha Pi haielekezi au njia inaelekea mahali pengine. Maombi kwenye tun0 bila majibu yanamaanisha upande wa nyumbani hauna njia ya kurudi au seva ilichuja pakiti. Majibu kwenye tun0 ambayo hayatokei tena kwenye br0 yanamaanisha kanuni ya kuchuja kinyume haipo, ambapo handaki inaonekana kamilifu na mteja bado haoni chochote.

Kisha vunja njia kwa makusudi. Shusha muunganisho wa modem na uinue tena na uendeshe tena ukaguzi wa njia na rekodi; njia inayostahimili handaki lakini inatoweka wakati wa kuunganisha tena ni ya wasifu wa muunganisho, si amri ya mara moja. Thibitisha kwamba usafirishaji wa handaki bado unatoka kupitia underlay na si kupitia yenyewe, kitanzi cha kawaida wakati njia ya msingi iliyosukumwa inakubaliwa bila njia ya mwenyeji kwa mwenzake.

Kubali muundo tu wakati mteja wa hotspot anaweza kutatua jina la nyumbani, kufungua huduma ya TCP na kuweka kikao hai katika muunganisho mmoja wa modem. Ikiwa programu inahitaji kweli ugunduzi wa kiwango cha Ethernet kwenye sehemu ya nyumbani, chagua muundo wa Layer 2 unaoungwa mkono badala ya kuelezea daraja la ndani kama limeunganishwa na kusubiri matangazo yatokeze.