Միացել եք OpenVPN-ին, բայց ոչինչ չի բեռնվում. ուղևորություն կլիենտից դեպի դուրս

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

Սկսեք կլիենտից և շարժվեք դեպի դուրս

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

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

Երկու որսում ցույց են տալիս, թե որտեղ են կանգ առնում փաթեթները

Երբ կլիենտից ping է ընթանում դեպի հանրային հասցե, վերցրեք մեկ որսում թունելի ինտերֆեյսի վրա և մեկը վերին կապի վրա, որը պետք է հասնի ինտերնետ։ Գործարկեք երկուսն էլ միաժամանակ, որպեսզի ժամանակի դրոշմները համընկնեն։

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

Վերին կապի անունը վերցրեք երթուղային աղյուսակից, ոչ թե ձեռնարկից։ Ամպային պատկերները և վերանվանված ադապտերները հազվադեպ են համընկնում ուղեցույցի օրինակ ինտերֆեյսի հետ, և սխալ սարքի վրա արված որսումը ճիշտ նույն տեսքն ունի, ինչ չփոխանցող սերվերը.

ip -4 route get 9.9.9.9

Այդ ելքի dev դաշտը այն անունն է, որը NAT կանոնին ավելի ուշ պետք կգա, ուստի պահեք այն։

Փոխանցումը միջուկի անջատիչ է և հրապարակախցիկի քաղաքականություն

Միջուկը պետք է ընդհանրապես համաձայնի փոխանցել։ Կարդացեք ընթացիկ արժեքը, ապա կարգավորումը դարձրեք մշտական՝ այն միայն աշխատող միջուկում գրելու փոխարեն.

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Փոխանցումը միայն կեսն է։ UFW օգտագործող հոսթում փոխանցման քաղաքականությունը սահմանվում է /etc/default/ufw-ում և պետք է ACCEPT լինի, նախքան վերաբեռնումը ուժի մեջ կմտնի։ Փոխանցման ուղու վրա լռելյայն գցումը ձեռքսեղմումը թողնում է լիովին առողջ, մինչդեռ լուռ դեն է նետում թունելով դուրս գալ փորձող յուրաքանչյուր փաթեթ, և դա հենց այն ախտանիշն է, որով սկսել եք։

nftables-ը ուղղակիորեն կառավարող հոսթերը նույն հարցն ունեն այլ շարահյուսությամբ։ Դիտեք փոխանցման շղթայի հաշվիչները, մինչ կլիենտի փորձարկումն ընթանում է, որովհետև հարցվող շղթան և գցող շղթան կոնֆիգուրացիայի ֆայլում նույն տեսքն ունեն։

NAT կանոնում անվանեք իրական ելքային ինտերֆեյսը

Աղբյուրի թարգմանությունը պատկանում է այն ինտերֆեյսին, որն իսկապես լքում է հոսթը, սերվերի բաշխած լողավազանի հետ։ Այդ կանոնի երկու կեսերն էլ պետք է նկարագրեն իրականությունը, և ոչ մեկը պարտադիր չէ։

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Դասական ձախողումը ուղեցույցից պատճենված կանոնն է, որն ասում է -o eth0 այն մեքենայի վրա, որի ադապտերը այլ անուն ունի։ Կանոնը տեղադրվում է առանց նախազգուշացման, ոչնչի չի համապատասխանում, և կլիենտը դեռ ինտերնետ չունի։ Լողավազանը նույն սխալի մյուս կեսն է. եթե սերվերը բաշխում է 10.44.0.0/24, իսկ կանոնը ծածկում է 10.8.0.0/24, ոչինչ երբեք չի համապատասխանի։

Դիտեք հաշվիչները՝ կանոնի տեքստին վստահելու փոխարեն։ Ցանկը հաղորդում է փաթեթները յուրաքանչյուր կանոնի համար, և երբեք չհամապատասխանող կանոնը մնում է զրոյի վրա, որքան էլ ճիշտ երևա։ Տվեք նրան մեկ րոպե իրական կլիենտի երթևեկություն, նախքան այդ թվից որևէ բան եզրակացնելը.

iptables -t nat -L POSTROUTING -v -n

Զրո փաթեթների հաշվարկը իրական կլիենտի փորձարկումից հետո նշանակում է, որ համընկնումը սխալ է, ոչ թե թունելը կոտրված է։ Երբ այն համընկնի, պահեք կանոնների հավաքածուն, որպեսզի այն վերապրի վերագործարկումը. ուղղումը, որն ապրում է միայն ձեր shell-ի պատմության մեջ, անհետանում է առաջին վերագործարկման ժամանակ։

Եթե սերվերը նաև ամպային NAT օրինակ է, հարթակն էլ իր խոսքն ունի։ Հասցեներ թարգմանող օրինակը սովորաբար պահանջում է անջատված աղբյուրի և նպատակակետի ստուգում այնտեղ, որտեղ մատակարարը տրամադրում է այդ կարգավորումը, և VPN պորտն ինքը պետք է հասանելի լինի դրսից։

DNS-ը երկրորդ ձախողումն է առաջինի հետևում

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

Ուղարկեք լուծիչ սերվերից, որպեսզի կլիենտն իմանա, թե որտեղ հարցնել։ Երկու գրառում կլիենտին պահուստ են տալիս, եթե առաջինը հասանելի չէ, և երկուսն էլ պետք է լինեն լուծիչներ, որոնք թունելն իսկապես թույլատրում է։

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows կլիենտները կարող են հետո այնուամենայնիվ վերադառնալ տեղական լուծիչին, և հենց դա կանխելու համար գոյություն ունի block-outside-dns-ը, բայց այն գնով, որ կորչեն անունները, որոնք միայն տեղական ցանցը կարող է լուծել։ systemd-resolved օգտագործող Linux կլիենտները հաճախ անտեսում են ուղարկված լուծիչը, եթե սկրիպտը չի տեղադրում այն, ուստի նախքան եզրակացնելը, որ ուղարկումն անտեսվել է, ստուգեք resolvectl status-ը թունելի սարքի համար։

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