VPN հաճախորդները միանում են, բայց ինտերնետ չկա՝ երեք բացակայող մաս

Հաճախորդը ստանում է հասցե, սերվերը պատասխանում է ping-ին, և այնուամենայնիվ յուրաքանչյուր էջ ժամանակավոր դադարի է հանդիպում։ Մարդկանց մեծ մասը այս պահին սկսում է խմբագրել հաճախորդի պրոֆիլը, ինչը սովորաբար վատնված ջանք է. երբ թունելը բարձրացած է, սերվերը պետք է իրեն պահի որպես երթուղիչ։ Երեք պայման պետք է միաժամանակ կատարվեն, նախքան փաթեթը դուրս կգա և պատասխանը կվերադառնա, և ախտանիշը նույնն է, անկախ նրանից, թե որն է բացակայում։

Ինչու աշխատող թունելը դեռ չունի դուրս գալու ուղի

Միջուկը պետք է փոխանցի փաթեթները ինտերֆեյսների միջև, ինչը լռելյայն անջատված է Linux-ի բաշխումների մեծ մասում։ Երթևեկությունը պետք է թարգմանվի այնպիսի հասցեի, որին արտաքին աշխարհը կարող է պատասխանել, եթե միայն յուրաքանչյուր վերին երթուղիչ արդեն չգիտի վերադարձի ուղին դեպի թունելի ենթացանց։ Հրապատի փոխանցման ուղին պետք է թույլատրի երթևեկությունը երկու ուղղությամբ՝ ներառյալ պատասխանները։

Այս ամենից յուրաքանչյուրը կարելի է շտկել առանձին, և հենց դա է որոգայթը։ Փոխանցումը միացնելը առանց թարգմանության կանոնի թողնում է փաթեթները դուրս գան մասնավոր աղբյուրով և առանց վերադարձի ուղու։ Թարգմանություն ավելացնելը առանց փոխանցման կանոնի թողնում է միջուկը գցի փաթեթը մեկ քայլ ուշ։

Այսպիսով, փորձարկեք երեք շերտերը, ոչ թե հաճախորդը, և փոխեք մեկը միաժամանակ, որպեսզի արդյունքը իմաստ ունենա։

Փոխանցումը միջուկի անջատիչ է, որը պետք է մշտական դարձնել

Փոխելուց առաջ ստուգեք ընթացիկ արժեքը, ապա սահմանեք այն և հաստատեք, որ փոփոխությունը ուժի մեջ է մտել։

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

Դարձրեք այն մշտական /etc/sysctl.d/-ի տակ գտնվող ֆայլում, ապա կիրառեք այդ ֆայլը՝ վերագործարկելու փոխարեն պարզելու համար։ FreeBSD-ում համարժեքը net.inet.ip.forwarding-ն է, իսկ մշտականության համար՝ gateway_enable=YES-ը rc.conf-ում։ Սարքը, որը հաղորդում է փոխանցման անջատված լինելու մասին, բացատրում է «փաթեթները գալիս են, և ոչինչ չի վերադառնում» տիպի ամբողջ դասի հաշվետվություններ։ Ստուգեք կարգավորումը նաև յուրաքանչյուր թարմացումից հետո, քանի որ վերակառուցված միջուկը կամ փոխարինված սարքի պատկերը կարող են վերականգնել այն՝ ոչ մեկին չասելով։

Ընտրեք masquerade կամ մեկ ֆիքսված թարգմանության հասցե

Դինամիկ արտաքին հասցեի դեպքում masquerading-ը ամենապարզ ճիշտ ձևն է։ Աղբյուր անվանեք թունելի ենթացանցը, իսկ ելք՝ արտաքին ինտերֆեյսը։

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Ստատիկ հանրային հասցեի դեպքում աղբյուրի թարգմանությունը հենց այդ հասցեին ավելի կանխատեսելի է և ավելի հեշտ ստուգելի։

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Երկրորդ ձևը կրում է սպասարկման որոգայթ. կոշտ կոդավորված հասցեն, որը հետագայում փոխվում է, թունելը պահում է աշխատող, մինչ ինտերնետ հասանելիությունը լուռ դադարում է։ Կամ օգտագործեք masquerade, կամ թարմացրեք կանոնը, երբ մատակարարը տեղափոխի ձեզ։ Ինտերֆեյսը նույնպես կարևոր է, քանի որ երթուղիչը, որը կիսում է իր սեփական վերին թունելը, պետք է թարգմանի այդ թունելով, ոչ թե ֆիզիկական WAN-ով։

Զտիչ աղյուսակը երրորդ դարպասն է

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

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Առաջին կանոնը թույլատրում է նոր երթևեկություն թունելից դուրս, իսկ երկրորդը՝ միայն պատասխանները հետ։ Նեղացրեք երկուսն էլ թունելի ենթացանցով և նախատեսված նպատակակետով, քանի որ թունելի ինտերֆեյսի վրա ընդհանուր թույլտվությունը VPN-ը դարձնում է բաց ելքային կետ ցանկացածի համար, ով կարող է նույնականացվել։

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

Ուր նայել, երբ էջը երբեք չի բեռնվում

Ping արեք սերվերի թունելի հասցեին՝ ապացուցելու, որ թունելը գոյություն ունի։ Ապա գործարկեք traceroute հաճախորդից դեպի հանրային հասցե և կարդացեք, թե որտեղ է այն կանգ առնում. սերվերի մոտ փաթեթը հասնում է, բայց չի փոխանցվում կամ թարգմանվում. սերվերից այն կողմ խնդիրը վերին մակարդակում է և ձեր ձեռքերից դուրս։

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

Սերվերի վրա դիտեք արտաքին ինտերֆեյսը, մինչ հաճախորդը էջ է բեռնում։ Մասնավոր աղբյուրի հասցեով դուրս եկող երթևեկությունը նշանակում է, որ թարգմանությունը բացակայում է, իսկ պատասխանի բացակայությունը՝ որ փոխանցման ուղին կամ վերին վերադարձի ուղին գցում է այն։

Եթե հեռավոր հաճախորդները պետք է հասնեն նաև սերվերի LAN-ի հոսթերին, հիշեք, որ LAN-ին պետք է վերադարձի ուղի դեպի թունելի ենթացանց։ Սա երթուղավորում է, ոչ թե թարգմանություն, և սա այն քայլն է, որն ամենից հաճախ մոռացվում է, երբ ինտերնետի ուղին վերջապես աշխատում է։