Pi-ի hotspot-ի հաճախորդները TUN VPN-ով չեն հասնում տնային LAN

Տեղական Wi-Fi և Ethernet հաճախորդները միանում են Pi-ի hotspot-ին, հասցե վերցնում նրա DHCP միջակայքից և առանց բողոքի բեռնում ինտերնետ էջեր։ Այնուհետև նույն հաճախորդները ժամանակը սպառում են, երբ տնային LAN-ում բացում են ֆայլերի համօգտագործում կամ վեբ ինտերֆեյս, մինչդեռ Pi-ն ինքը հասնում է այդ LAN-ին թունելով։ Անլար շերտում ոչինչ կոտրված չէ։ Բացակայում է երթուղավորված պայմանագիր՝ hotspot-ի նախածանցը պետք է տարվի TUN ինտերֆեյս, և տնային կողմում ինչ-որ բան պետք է իմանա, թե ինչպես պատասխանները հետ ուղարկել այնտեղ։ Երկու կեսերն էլ պետք է գոյություն ունենան, որպեսզի մեկ փաթեթը կարողանա ավարտել գնալ-վերադառնալ ուղին։

Երեք միացում՝ երեք տարբեր աշխատանքով

Linux Ethernet կամուրջը փոխանցում է շրջանակները ըստ նպատակակետ MAC հասցեի։ OpenVPN TUN ռեժիմում կրում է IP փաթեթներ և ընդհանրապես MAC շերտ չունի, ուստի տեղական կամուրջ ավելացնելը երբեք թունելը չի գրանցում որպես պորտ։ միջուկի TUN/TAP փաստաթղթերը բացատրում են այդ բաժանումը՝ TAP սարքը նման է Ethernet ինտերֆեյսի, TUN սարքը՝ ոչ։ Երկու տեղական պորտ կամրջող, ապա երթուղավորող նախագիծը երթուղիչ է, ինչ էլ ասեն ինտերֆեյսների անունները։

Այդ տարբերությունը որոշում է սեփականությունը։ Հաճախորդների ենթացանցը, նրանց լռելյայն դարպասը և այդ միջակայքի DHCP լիազորությունը պատկանում են Pi-ի տեղական պլանին։ Տնային DHCP հեռարձակումները չեն անցնում երթուղավորված թունելով, և ոչ մի կամրջի կարգավորում դա չի փոխում՝ հաճախորդներին տնային DHCP սերվերին ուղղելը առանձին, դիտավորյալ ռելե նախագիծ է՝ իր ձախողման եղանակներով։

Մոդեմը նույնպես պահեք հաճախորդների կամրջից դուրս։ PPP միացումը այլ պիտակով Ethernet սարք չէ, և pppd-ի փաստաթղթավորված լռելյայն երթուղու տրամաբանությունը աշխատում է IPCP բանակցություններից հետո և հետ է վերցնում իր երթուղին, երբ այդ կապը ընկնում է։ DHCP ձևանմուշը պատճենելը և յուրաքանչյուր usb0-ը ppp0 վերանվանելը ոչինչ չի ապացուցում դարպասի, մետրիկայի կամ կյանքի ցիկլի մասին։

Ընտրեք նախածանցերը՝ նախքան որևէ կոնֆիգուրացիա խմբագրելը

Համընկնող նախածանցերը ավելի շատ երեկոներ են վատնում, քան firewall-ի կանոնները, որովհետև համընկնումը երթուղու որոնումը ուղարկում է սխալ ինտերֆեյս նույնիսկ երբ թունելը առողջ է։ Սկսեք ցանկից, թե ինչ արդեն կա Pi-ում, ապա արդյունքը կարդացեք որպես չորս առանձին ավազան։

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

Առաջին ավազանը underlay հասցեն է, որը օպերատորը տվել է մոդեմին՝ այն պետք է մնա հաճախորդներին ուղղված բոլոր պլաններից դուրս։ Երկրորդը թունելի ենթացանցն է, որն ընտրել է սերվերը, հաճախ իր սեփական մասնավոր /24-ը։ Երրորդը hotspot-ի կամուրջն է, իսկ չորրորդը տնային նախածանցն է, որին ուզում եք հասնել։ Այս քայլում hotspot-ը ստանում է 172.28.90.0/24՝ կամուրջը 172.28.90.1-ի վրա, իսկ տնային ծառայության LAN-ը պահում է 192.168.77.0/24-ը, ինչը խուսափում է սպառողական երթուղիչների հետ եկող 192.168.1.0/24 և 10.0.0.0/24 լռելյայններից և օպերատորի 100.64.0.0/10 միջակայքից։

Hotspot-ի DHCP միջակայքում որպես դարպաս հայտարարեք միայն կամրջի հասցեն և ուրիշ ոչինչ։ Երբեք hotspot հաճախորդներին որպես դարպաս մի տվեք տնային հասցե՝ նրանք կապի շերտում ուղի չունեն դեպի այդ սեգմենտը։

Երթուղավորեք յուրաքանչյուր ուղղություն այն կողմում, որն այն տիրապետում է

Pi-ին պետք է երթուղի տնային նախածանցի համար թունելով։ Սերվերը սերվեր ռեժիմում սովորաբար հրում են այդ երթուղին, ուստի նախ հաստատեք, որ փոխանցումը միացված է, և որ միջուկը տնային հասցեն լուծում է tun0-ից։

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

Եթե ip route get դեռ հաղորդում է underlay ինտերֆեյսի մասին, կանգ առեք այնտեղ՝ ուղու հետագա ոչինչ չի կարող ուղղել սխալ որոնումը։

Տնային սարքերը երթուղի չունեն դեպի 172.28.90.0/24, ուստի նրանց պատասխանները հետևում են լռելյայն դարպասին և մեռնում երթուղիչում։ Գոյություն ունեն երկու աջակցվող վերանորոգում։ Կամ ավելացրեք ստատիկ երթուղի տնային երթուղիչում, որը hotspot նախածանցը ուղղում է VPN սերվերի LAN հասցեին, կամ, երբ սերվերն ինքն է դարպասը, գրանցեք հաճախորդի նախածանցը սերվերի սեփական երթուղային աղյուսակում։ OpenVPN-ի բազմահաճախորդ ռեժիմում հաճախորդին հատուկ գրացուցակը կրում է այդ կապը՝ ֆայլ՝ անվանված հաճախորդի վկայագրի ընդհանուր անունով, որը պարունակում է iroute 172.28.90.0 255.255.255.0 և համապատասխան route տողը, որն այն տեղադրում է սերվերի միջուկում։ Սերվերի վրա գուշակված միջուկի երթուղին նույն պնդումը չէ, ինչ սերվերին ասելը, թե որ հաճախորդն է տիրապետում նախածանցին։

Մի տեղափոխեք տնային ցանցի DHCP ծառայությունը VPN սերվեր, որպեսզի սա աշխատի։ Ամբողջ տան լռելյայն դարպասը փոխարինելը շատ ավելի մեծ փոփոխություն է, քան մեկ մասնավոր վերադարձի երթուղի ավելացնելը, և այն DNS-ը, հասցեների արգելոցները և նոր վարձակալությունը անտեսող յուրաքանչյուր սարք քաշում է ձախողման մեջ։

Բացեք փոխանցումը՝ առանց firewall-ի մասին գուշակելու

Փոխանցման միացված լինելը չի նշանակում, որ փաթեթին թույլատրված է անցնել։ Կամրջից թունել երթևեկությունը դեռ բախվում է զտման կանոններին, և լռելյայն drop փոխանցման քաղաքականությունը գցում է hotspot երթևեկությունը, մինչ Pi-ի սեփական երթևեկությունը շարունակում է աշխատել, ինչը արտադրում է հենց վերևի բաժանված ախտանիշը։

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

Փնտրեք թույլտվության կանոն br0-ից tun0 և համապատասխան պատասխանի ուղղություն, ինչպես նաև postrouting կանոն, որը կարող է վերաշարադրել աղբյուրը։ Եթե շղթայի քաղաքականությունը drop է և ոչ մի կանոն չի համընկնում, ավելացրեք նեղ թույլտվությունները և նորից փորձարկեք՝ քաղաքականությունը accept-ի դարձնելու փոխարեն։

Թարգումը քաղաքականության ընտրություն է, ոչ պահանջ։ Աղբյուրի NAT-ը դեպի տնային LAN ստիպում է յուրաքանչյուր hotspot հաճախորդի նմանվել Pi-ի թունելի հասցեին, ինչը կորցնում է հաճախորդով պայմանավորված վերագրումը տնային մատյաններում և կոտրում է ծառայություններ, որոնք սպասում են բնօրինակ աղբյուրին։ Առանց NAT-ի երթուղավորումը հաճախորդների հասցեները պահում է տեսանելի, բայց կախված է վերևի վերադարձի երթուղուց։ Ընտրեք մեկը և DNS-ին ու IPv6-ին վերաբերվեք նույն կերպ, որովհետև կոտրված IPv6 ուղու կողքին աշխատող IPv4 ուղին դեռ բրաուզերում կարդացվում է որպես կիսով կոտրված։

Ստուգեք գնալ-վերադառնալ ուղին, ապա դիտավորյալ կոտրեք այն

Փորձարկեք hotspot հաճախորդից, երբեք Pi-ից, որովհետև Pi-ի սեփական երթևեկությունը շրջանցում է և՛ առաջ, և՛ վերադարձի ուղին։ Դիտեք երկու ինտերֆեյսները, մինչ մեկ հաճախորդ փորձում է հասնել տնային ծառայության։

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

Կարդացեք երկու որսումները միասին։ br0-ի վրա հարցումները, որոնք երբեք չեն երևում tun0-ի վրա, նշանակում են, որ Pi-ն չի փոխանցում կամ երթուղին ուրիշ տեղ է ցույց տալիս։ tun0-ի վրա առանց պատասխանների հարցումները նշանակում են, որ տնային կողմը վերադարձի երթուղի չունի կամ սերվերը զտել է փաթեթը։ tun0-ի վրա պատասխանները, որոնք երբեք նորից չեն երևում br0-ի վրա, նշանակում են, որ հակառակ զտման կանոնը բացակայում է, երբ թունելը կատարյալ է երևում, իսկ հաճախորդը դեռ ոչինչ չի տեսնում։

Ապա դիտավորյալ կոտրեք ուղին։ Անջատեք մոդեմի կապը և նորից միացրեք ու վերսկսեք երթուղու և որսման ստուգումները՝ երթուղին, որը վերապրում է թունելը, բայց անհետանում է վերամիացման ժամանակ, պատկանում է կապի պրոֆիլին, ոչ թե մեկանգամյա հրամանին։ Համոզվեք, որ թունելի տրանսպորտը դեռ դուրս է գալիս underlay-ով, ոչ իր միջով, դասական հանգույց, երբ հրված լռելյայն երթուղին ընդունվում է առանց հանգույցի երթուղու դեպի զուգընկերը։

Ընդունեք նախագիծը միայն այն ժամանակ, երբ hotspot հաճախորդը կարող է լուծել տնային անուն, բացել TCP ծառայություն և մեկ մոդեմի վերամիացման ընթացքում սեսիան կենդանի պահել։ Եթե հավելվածն իսկապես պահանջում է Ethernet մակարդակի հայտնաբերում տնային սեգմենտում, ընտրեք աջակցվող Layer 2 նախագիծ՝ տեղական կամուրջը կամրջված անվանելու և հեռարձակման սպասելու փոխարեն։