hostapd-ը և OpenVPN-ը մեկ Pi-ի վրա. ո՞ւմն է լռելյայն երթուղին։

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

Թվարկեք ինտերֆեյսները, նախքան որևէ բան խմբագրելը

Ծանոթ դասավորությունը անլար ռադիոն և լարային պորտը դնում է br0-ի ներսում, գործարկում է hostapd-ը կամրջի դեմ և բաշխում է վարձույթներ dnsmasq-ից, մինչ OpenVPN հաճախորդը ստեղծում է tun0-ը։ Այնուհետև երեք առանձին պահանջներ մեկի տեսք ունեն՝ մուտքի կետի հաճախորդներին Pi-ն պետք է որպես դարպաս, Pi-ին պետք է երթուղի դեպի ինտերնետ՝ իր սերվերին հասնելու համար, իսկ կամրջին պետք է դարպասի հասցե, որը այդ հաճախորդները կարող են օգտագործել։

Կարդացեք ներկա վիճակը նախքան այն փոխելը, քանի որ այս չորս հրամանները տարանջատում են ինտերֆեյսի խնդիրը երթուղային խնդրից։

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

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

Տվեք կամրջին լռելյայն երթուղի, որը պատկանում է իրեն

Raspberry Pi OS-ը հաճախ կամուրջը թողնում է առանց լռելյայն երթուղու, երբ կամուրջը ստեղծվել է ինտերֆեյսի ֆայլը գրելուց հետո։ Բլոկը պատկանում է /etc/dhcpcd.conf-ին, և այն պետք է նշի վերին երթուղիչը, ոչ թե 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

Այդ օրինակում 192.168.50.1-ը գոյություն ունեցող երթուղիչն է, իսկ 192.168.50.2-ը Pi-ի կամրջի հասցեն է նույն ենթացանցում, ուստի փոխարինեք ձեր սեփական պլանով՝ թվերը պատճենելու փոխարեն։ Կամրջի անդամները նույնպես չպետք է երթուղիչներ պահանջեն, այլապես Pi-ն կստանա մրցակցող լռելյայն երթուղիներ, որոնց հաղթողը կախված է մետրիկայից և ժամանակից, ոչ թե մտադրությունից։

systemctl restart dhcpcd-ից հետո ip route show default-ը պետք է մեկ անգամ թվարկի br0-ը և լարային պորտից կրկնօրինակ չլինի։ Հաստատեք որոնումը, ոչ թե աղյուսակը, քանի որ հին գրառումը կարող է նստել հաղթողի կողքին՝ ip -4 route get 203.0.113.10-ը պետք է անվանի br0-ը։ Այդ հասցեն գալիս է TEST-NET-3 փաստաթղթային տիրույթից, ուստի այն չի կարող բախվել իրական սերվերի հետ, մինչ դուք սա կարդում եք։

Թույլ մի տվեք, որ թունելը առևանգի ուղին դեպի իր սեփական սերվերը

OpenVPN հաճախորդը, որն ընդունում է redirect-gateway-ը, վերցնում է լռելյայն երթուղին և ուղղում այն թունելի մեջ։ Դա ճիշտ է, երբ մուտքի կետի բոլոր հաճախորդները պետք է օգտագործեն VPN-ը, և սխալ, երբ պետք է միայն որոշ նպատակակետեր։ Ամեն դեպքում, Pi-ի սեփական կապը սերվերի հետ չպետք է ճամփորդի այն թունելի ներսում, որը դեռ կառուցում է։ OpenVPN-ը ավելացնում է հոսթի երթուղի դեպի հեռավոր կողմը բնօրինակ դարպասով, երբ վերահասցեավորում է լռելյայնը, և դա հենց այն վարքագիծն է, որը կենդանի է պահում տրանսպորտը, և եթե այդ երթուղին բացակայում է, թունելը փլուզվում է հենց որ հաստատվում է։

Այդ տրանսպորտային ուղու արագ համեմատությունը միանալուց առաջ և հետո արժե այն տասը վայրկյանը։ ip -4 route get 203.0.113.10-ը պետք է անվանի ստորին շերտի սարքը երկու վիճակներում էլ, փոխվում է միայն մետրիկան։ Եթե թունելի բարձրանալուց հետո այն անվանում է tun0-ը, հոսթի երթուղին երբեք չի տեղադրվել, և հաջորդ վերամիացումը կձախողվի։

Երբ միայն ընտրված նախածանցները պետք է անցնեն թունելով, օգտագործեք route-nopull-ը և ավելացրեք ցանկալի երթուղիները ձեռքով, կամ սերվերից ուղարկեք ավելի նեղ հավաքածու։ Կամուրջը պահում է լռելյայն երթուղին այդ ձևավորման մեջ, և DNS-ը դառնում է հաջորդ որոշումը՝ dnsmasq-ի փոխանցումը տնային լուծիչին իմաստ ունի միայն այն անունների համար, որոնք իրոք ապրում են այնտեղ։

Որոշեք փոխանցման և NAT-ի հարցը

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

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 կանոնը այն կարճուղին է, որն աշխատում է, երբ սերվերը չի ընդունի մուտքի կետի նախածանցը, այն գնով, որ յուրաքանչյուր հաճախորդ հեռավոր կողմի մատյաններում երևա որպես Pi-ի թունելի հասցե։ Նախածանցի երթուղավորումը առանց NAT-ի հասցեները տեսանելի է պահում և կախված է տնային կողմում 192.168.50.0/24-ի համար վերադարձի երթուղուց։

Գրեք ընտրությունը firewall-ի կանոնների կողքին, քանի որ ձևավորման մեջ անտեսանելի NAT կանոնը վեց ամիս անց անբացատրելի է դառնում։ Պահեք IPv6-ը նույն որոշման մեջ, իսկ աշխատող IPv4 ուղին կոտրված IPv6 ուղու կողքին դեռևս կիսակոտրված է ընթերցվում զննարկիչում։

Ստուգեք հաճախորդից, ապա մաքուր հետշրջեք

Փորձարկեք այս հերթականությամբ հեռախոսից կամ նոութբուքից մուտքի կետում՝ վարձույթ dnsmasq-ից, ping կամրջի հասցեին, ապա նպատակակետ թունելի հեռավոր կողմում։ Յուրաքանչյուր քայլ մեկուսացնում է մեկ շերտ, փոխարենը մեկ անօգուտ ձախողում արտադրելու։

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

Ապա հաստատեք, որ Pi-ն դեռ ունի իր սեփական ելքը՝ ip route get 203.0.113.10-ը պետք է անվանի ստորին շերտի սարքը, և ping -c 3 -I br0 203.0.113.10-ը պետք է պատասխանի, եթե սերվերը թույլատրում է ICMP։ Եթե հաճախորդի առաջին երկու քայլերը անցնում են, իսկ երրորդը ձախողվում է, խափանումը փոխանցման կամ NAT-ի մեջ է։ Եթե երկրորդ քայլը ձախողվում է, կամուրջը կամ DHCP-ն դեռ թերի են։

Հետշրջումը մեկ ֆայլի խմբագրում և երկու հրաման է՝ հեռացրեք բլոկը, վերագործարկեք dhcpcd-ն և փոխարինեք լռելյայն երթուղին բացահայտ ip route replace default via 192.168.50.1 dev br0-ով։ Արեք դա սպասարկման պատուհանի փակվելուց առաջ, ոչ թե հետո, քանի որ լռելյայն երթուղին կորցրած Pi-ն անհասանելի է այն ցանցից, որը կօգտագործեիք այն վերանորոգելու համար։