Staðbundnir Wi-Fi- og Ethernet-viðskiptavinir tengjast hotspot Pi, sækja tölu úr DHCP-sviði þess og hlaða vefsíðum án kvartana. Sömu viðskiptavinir lenda svo í tímaútrunni þegar þeir opna skráardeilingu eða vefviðmót á heimilis-LANinu, á meðan Pi sjálft nær því LANi í gegnum göngin. Ekkert í þráðlausa laginu er bilað. Það sem vantar er bein leið samnings: hotspot-forskeytið verður að bera inn í TUN-viðmótið, og eitthvað á heimilishliðinni verður að vita hvernig á að senda svör til baka. Báðir helmingar verða að vera til áður en eitt pakki getur lokið ferðinni fram og til baka.

Þrjár tengingar með þremur mismunandi verkum

Linux Ethernet-brú sendir ramma eftir MAC-heimilisfangi áfangastaðar. OpenVPN í TUN-ham ber IP-pakka og hefur alls ekki MAC-lag, svo að bæta við staðbundinni brú skráir göngin aldrei sem port. TUN/TAP-skjöl kjarnans útskýra þá skiptingu: TAP-tæki lítur út eins og Ethernet-viðmót, TUN-tæki ekki. Hönnun sem brúar tvö staðbundin port og beinir svo er beinir, hvað sem viðmótsnöfnin segja.

Sú aðgreining ræður eignarhaldi. Undirnet viðskiptavinanna, sjálfgefna gátt þeirra og DHCP-heimild fyrir það svið tilheyra staðbundnu áætlun Pi. Heimilis-DHCP-útvarp fer ekki yfir beinda göng og engin brúarstilling breytir því; að beina viðskiptavinunum að heimilis-DHCP-þjóni er sérstök, viljandi endursendingarhönnun með eigin bilunaraðferðum.

Haltu mótaldinu líka utan viðskiptavinabrúarinnar. PPP-tenging er ekki Ethernet-tæki með annan merkimiða, og skjalfest sjálfgefin leiðar-rökfræði pppd keyrir eftir IPCP-samningaviðræður og dregur leið sína til baka þegar þessi tenging dettur. Að afrita DHCP-sniðmát og endurnefna hvert usb0 í ppp0 sannar ekkert um gátt, mælikvarða eða lífsferil.

Veldu forskeytin áður en þú breytir hvaða stillingum sem er

Skörun forskeyta eyðir fleiri kvöldum en eldveggjareglur, því skörun sendir leiðarleitina á rangt viðmót jafnvel þegar göngin eru heilbrigð. Byrjaðu á að skrá það sem þegar er til á Pi, lestu svo niðurstöðuna sem fjögur aðskilin sund.

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

Fyrsta sundið er underlay-heimilisfangið sem flutningsaðilinn gaf mótaldinu; það verður að vera utan við hverja áætlun sem snýr að viðskiptavinum. Annað er göngaundirnetið sem þjónninn valdi, oft eigið einkaað /24-net. Þriðja er hotspot-brúin, og fjórða er heimilisforskeytið sem þú vilt ná. Í þessari göngu fær hotspottið 172.28.90.0/24 með brúna á 172.28.90.1, og heimilishjónustu-LAN heldur 192.168.77.0/24, sem kemst hjá sjálfgefnu 192.168.1.0/24 og 10.0.0.0/24 sem neytendabeinar koma með og flutningsaðilasviðinu 100.64.0.0/10.

Tilkynntu brúarheimilisfangið sem gátt í DHCP-sviði hotspotsins og ekkert annað. Gefðu hotspot-viðskiptavinum aldrei heimilisfang sem gátt; þeir hafa enga slóð á tengilagi að því sviði.

Beindu hverri átt á þeirri hlið sem á hana

Pi þarf leið fyrir heimilisforskeytið í gegnum göngin. Þjónar í þjónaham ýta venjulega þeirri leið, svo staðfestu fyrst að framsending sé virk og að kjarninn leysi heimilisfang úr tun0.

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

Ef ip route get greinir enn frá underlay-viðmótinu, stöðvaðu þar; ekkert lengra eftir slóðinni getur lagað ranga leit.

Heimilistæki hafa enga leið að 172.28.90.0/24, svo svör þeirra fylgja sjálfgefnu gáttinni og deyja við beininn. Tvær studdar viðgerðir eru til. Annaðhvort bætirðu kyrrstæðri leið við á heimilisbeininum sem beinir hotspot-forskeytinu að LAN-heimilisfangi VPN-þjónsins, eða, þegar þjónninn er sjálfur gáttin, skráirðu forskeyti viðskiptavinarins í eigin leiðatöflu þjónsins. Í fjölviðskiptavinaham OpenVPN ber viðskiptavinasértæka möppan þá tengingu: skrá nefnd eftir algengu nafni viðskiptavinarskírteinis, sem inniheldur iroute 172.28.90.0 255.255.255.0 auk samsvarandi route-línu sem setur hana í kjarna þjónsins. Ágiskun leiðar í kjarna þjónsins er ekki sama fullyrðing og að segja þjóninum hvaða viðskiptavinur á forskeytið.

Færðu DHCP-þjónustu heimilisnetsins ekki yfir á VPN-þjóninn til að láta þetta virka. Að skipta um sjálfgefna gátt fyrir heilt hús er mun stærri breyting en að bæta við einni einkaafturleið, og hún dregur DNS, töluáskriftir og hvert tæki sem hunsar nýja leiguna inn í bilunina.

Opnaðu framsendingu án þess að giska á eldvegginn

Virk framsending þýðir ekki að pakkinn megi fara í gegn. Umferð frá brúnni að göngunum rekst enn á síunarreglurnar, og sjálfgefin drop-framsendingarstefna hendir hotspot-umferð á meðan eigin umferð Pi heldur áfram að virka, sem framleiðir nákvæmlega klofna einkennið hér að ofan.

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

Leitaðu að samþykkisreglu frá br0 að tun0 og samsvarandi svarshætti, og að postrouting-reglu sem gæti endurskrifað uppsprettuna. Ef keðjustefnan er drop og engin regla passar, bættu við þröngu samþykkin og prófaðu aftur í stað þess að snúa stefnunni í accept.

Þýðing er stefnuval, ekki krafa. Uppsprettu-NAT í átt að heimilis-LANinu lætur hvern hotspot-viðskiptavin líta út eins og gönguheimilisfang Pi, sem tapar rekjanleika á hvern viðskiptavin í heimilislógum og brýtur þjónustur sem búast við upprunalegu uppsprettunni. Beining án NAT heldur viðskiptavinatölum sýnilegum en er háð afturleiðinni hér að ofan. Veldu eina og meðhöndlaðu DNS og IPv6 á sama hátt, því að virk IPv4-slóð við hlið brostinnar IPv6-slóðar lesst enn sem hálf brostin í vafra.

Staðfestu ferðina fram og til baka og brjóttu hana svo viljandi

Prófaðu frá hotspot-viðskiptavini, aldrei frá Pi, því eigin umferð Pi fer fram hjá bæði framleiðinni og afturleiðinni. Fylgstu með báðum viðmótum á meðan einn viðskiptavinur reynir að ná heimilisþjónustu.

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

Lestu báðar upptökurnar saman. Beiðnir á br0 sem birtast aldrei á tun0 þýða að Pi framsendir ekki eða leiðin vísar annað. Beiðnir á tun0 án svara þýða að heimilishliðin hefur enga afturleið eða þjónninn síaði pakkann. Svör á tun0 sem birtast aldrei aftur á br0 þýða að öfug síunarreglan vantar, þar sem göngin líta fullkomin út og viðskiptavinurinn sér samt ekkert.

Brjóttu svo slóðina viljandi. Taktu mótaldstenginguna niður og upp aftur og keyrðu leiðar- og upptökuskoðanirnar aftur; leið sem lifir göngin en hverfur við endurtengingu tilheyrir tengingarsniðinu, ekki einnota skipun. Staðfestu að flutningur ganganna fari enn út um underlay og ekki í gegnum sjálfan sig, klassíska lykkjan þegar ýtt sjálfgefin leið er samþykkt án hýsil-leiðar að jafningjanum.

Samþykktu hönnunina aðeins þegar hotspot-viðskiptavinur getur leyst heimilisnafn, opnað TCP-þjónustu og haldið lotu lifandi yfir eina mótaldstengingu. Ef forrit krefst í raun Ethernet-stigs uppgötvunar á heimilissviðinu, veldu studda Layer 2-hönnun í stað þess að lýsa staðbundnu brúnni sem brúaðri og bíða eftir að útvarp birtist.

Tengdir greinar