WireGuard-ի ձեռքսեղմումն աշխատում է, բայց ինտերնետ չկա. հետևեք փաթեթին
Ձեռքսեղմումը վկայում է միայն բանալիներն ու հասանելիությունը։ Հետևեք մեկ փաթեթին AllowedIPs-ից փոխանցման, NAT-ի և վերադարձի երթուղու միջով՝ տեսնելու, թե որտեղ է այն կանգ առնում։
Թունելը բաց է, wg show-ը ցույց է տալիս վերջերս կատարված ձեռքսեղմում, կարող եք ping անել սերվերի թունելի հասցեին, և դրանից այն կողմ ոչինչ չի պատասխանում։ Առաջին միտքը բանալիները վերստեղծելն է կամ կազմաձևը նորից կիսելը։ Դա փոխում է հենց այն հատվածը, որն արդեն ապացուցված է, որ աշխատում է։
Ավարտված ձեռքսեղմումը ասում է, որ երկու կողմերը համաձայն են բանալիների շուրջ, որ UDP-ն հասնում է վերջնակետին, և որ գաղտնագրված երթուղումը ընդունում է փաթեթը։ Այն ոչինչ չի ասում այն մասին, թե արդյոք փաթեթը կարող է դրանից հետո լքել սերվերը։
Ուստի գուշակելու փոխարեն հետևեք մեկ փաթեթին։ Կան չորս վայրեր, որտեղ այն կարող է մահանալ, և յուրաքանչյուրը թողնում է տարբեր հետք։
Ինչ է իրականում ապացուցում ձեռքսեղմումը
WireGuard-ը UDP արձանագրություն է, որը Noise ձեռքսեղմումով նստաշրջան է հաստատում, ապա գաղտնագրում փաթեթները զուգընկերոջ համար։ Երբ wg show-ը ցույց է տալիս մի քանի վայրկյան առաջ կատարված ձեռքսեղմում և աճող փոխանցման հաշվիչ, վերջնակետը, բանալիները և զուգընկերոջ հանրային բանալին բոլորն էլ ճիշտ են։
Ինչը նա չի ապացուցում. որ ձեր հաճախորդն ընդհանրապես ինտերնետային թրաֆիկ ուղարկում է ինտերֆեյս, որ սերվերը պատրաստ է այն փոխանցել, կամ որ պատասխանը կարող է գտնել վերադարձի ճանապարհը։ Դրանք միջուկի երթուղման և firewall-ի որոշումներ են, և կայացվում են թունելից դուրս։
Այդ պատճառով սերվերի թունելի հասցեին ping անելը այդքան մոլորեցնող փորձարկում է։ Այդ փաթեթը հասցեագրված հենց սերվերին, ուստի այն ավարտվում է տեղում։ Այն երբեք փոխանցման կարիք չունի, երբեք՝ թարգմանության, և երբեք՝ ինտերնետից վերադարձի երթուղու։
AllowedIPs-ը երթուղման որոշում է
Հաճախորդի վրա AllowedIPs-ը երկու աշխատանք է կատարում։ Դա գաղտնաբանալիի երթուղման աղյուսակն է, որը որոշում է, թե որ նպատակակետ հասցեներն են ուղարկվում այս զուգընկերոջ թունել, և դա աղբյուր հասցեների ցանկն է, որը զուգընկերը կընդունի ձեզանից։ Եթե հաճախորդի կազմաձևում նշված է միայն 10.8.0.0/24, հանրային նպատակակետերը երբեք չեն մտնում ինտերֆեյս, և ձեր սովորական լռելյայն երթուղին դրանք տանում է թունելից դուրս։ Այդ դեպքում թունելը կատարյալ աշխատում է և ոչինչ չի անում ձեր ուզածից։
Նայեք, թե ինչ է հաճախորդն իրականում տեղադրել, այլ ոչ թե ինչ է ասում կազմաձևի ֆայլը.
wg show wg0 allowed-ipsip route get 1.1.1.1
Երկրորդ հրամանը վճռորոշն է։ Եթե պատասխանը նշում է ձեր ֆիզիկական ինտերֆեյսը և սովորական դարպասը, փաթեթը թունելով չի գնում, և սերվերի կողմի ոչ մի փոփոխություն դա չի ուղղի։ Ավելացրեք 0.0.0.0/0-ը IPv4-ի և ::/0-ը IPv6-ի համար առանձին. մի ընտանիքի համար ամեն ինչ ընդգրկող կանոնը մյուսին թողնում է իր սկզբնական ուղու վրա, և սա աշխատող IPv4 թունելի և կանգնած IPv6 որոնման հաճախակի պատճառն է։
Որտեղ է փաթեթը մահանում դարպասի վրա
Եթե երթուղին ճիշտ է, և փաթեթը դեռ ոչ մի տեղ չի գնում, այն հասնում է սերվերին և կանգ է առնում այնտեղ։ Չորս ստուգում ընդգրկում են դարպասների մեծ մասը։
Փոխանցում։ sysctl net.ipv4.ip_forward-ը, որը վերադարձնում է 0, դասական պատասխանն է, և շատ տարածումներ դեռ լռելյայն 0-ի վրա են։ Այն պետք է լինի 1, և պետք է մշտապես սահմանվի sysctl ֆայլում, այլ ոչ թե հրամանով, որը անհետանում է վերագործարկման ժամանակ։ IPv6-ի փոխանցումը առանձին անջատիչ է։
Զտման քաղաքականությունը։ Լռելյայն drop քաղաքականությամբ FORWARD շղթան կշպրտի թունելի թրաֆիկը, մինչդեռ կթույլատրի թրաֆիկը դեպի հենց հոսթը, ինչը ճիշտ համընկնում է ախտանշանի հետ։ Կարդացեք կենդանի կանոնների հավաքածուն, ոչ թե պահված ֆայլ. nft list ruleset կամ iptables -S։
Թարգմանություն կամ երթուղում։ Մասնավոր թունելային հասցեներ օգտագործող հաճախորդներին անհրաժեշտ է կա՛մ աղբյուրի NAT սերվերի ելքի ինտերֆեյսի վրա, կա՛մ երթուղված նախածանց, որը վերին ցանցը գիտի վերադարձնել։ Նրանց միջև ընտրությունը հետևում է հասցեների պլանին։ MASQUERADE ավելացնելը ցանցին, որն արդեն ետ է երթուղում ձեր նախածանցը, անվնաս է, բայց անիմաստ, իսկ այն բաց թողնելը այնտեղ, որտեղ երթուղի չկա, պատասխանները թողնում է ուղղված չերթուղվող մասնավոր տիրույթի։
Վերադարձի ուղին։ Երթուղված ձևավորումներում վերին երթուղիչին անհրաժեշտ է երթուղի, որը մատնանշում է ձեր սերվերին։ Մատակարարի ցանցը նույնպես կարող է արգելափակել այն. մի քանի ամպեր միացնում են աղբյուրի և նպատակակետի ստուգում instance-ի վրա, որը լուռ դեն է նետում այն փաթեթները, որոնց աղբյուրը instance-ի սեփական հասցեն չէ, մինչև այդ ստուգումը չանջատվի։
DNS-ը ձախողվում է այլ կերպ, քան երթուղումը
Փաթեթը հայտնի հասցեին և անվան որոնումը երկու առանձին ձախողումներ են, և սխալի հաղորդագրությունները մոլորեցնում են հակառակ ուղղություններով։ Եթե ping 1.1.1.1-ը աշխատում է, և զննարկիչը ոչինչ չի բեռնում, երթուղին կարգին է, իսկ անունների լուծումը՝ ոչ։ Եթե ping-ն ինքն է ձախողվում, DNS-ը անտեղի է, և դուք վերադարձել եք նախորդ բաժին։
wg-quick-ը կարող է resolver սահմանել կազմաձևի DNS = տողից, և systemd-resolved-ն ունի իր վարքը յուրաքանչյուր կապի համար։ VPN-ը, որը resolver-ը փոխարինում է մի հասցեով, որը հասանելի է միայն թունելի ներսում, կձախողի յուրաքանչյուր որոնում այն պահին, երբ թունելը ընկնում է, ինչը երևում է այնպես, կարծես թունելը կոտրում է ինտերնետը։
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
Հերթականություն, որը ապացույցներ է տալիս
Նախ կատարեք հաճախորդի կողմի ստուգումը, որովհետև դա մեկ հրաման է և վերացնում է հնարավորությունների կեսը։ Ապա հաստատեք, թե արդյոք սերվերը ընդհանրապես նախատեսված է որպես ինտերնետի ելք. մասնավոր մուտքի համար կառուցված դարպասը կոտրված չէ, երբ հանրային նպատակակետերը ձախողվում են։
Սերվերի վրա հետևեք ինտերֆեյսին, մինչ հաճախորդից ping եք ուղարկում. tcpdump -ni wg0 icmp-ը պետք է ցույց տա հարցումը, և tcpdump -ni eth0 icmp-ը պետք է ցույց տա, որ այն դուրս է գալիս՝ թարգմանված, թե ոչ։ Եթե այն հայտնվում է առաջինի վրա և երբեք՝ երկրորդի, կանգառը տեղական է սերվերի համար։ Եթե այն դուրս է գալիս, և պատասխան չի վերադառնում, խնդիրը վերևում է, և դա այլ խոսակցություն է։
Վերջում արեք այնպես, որ ուղղումը դիմանա վերագործարկմանը։ Փոխանցումը տեղ ունի sysctl ֆայլում, firewall-ի կանոնները՝ այն ծառայության մեջ, որը բեռնում է դրանք, իսկ հաճախորդի երթուղիները՝ կազմաձևում, որը բարձրացնում է ինտերֆեյսը, այլ ոչ թե shell-ում, որը կմոռանաք։ Նորից միացեք, կրկնեք նույն երկու փորձարկումները և հաստատեք, որ հաշվիչները շարժվում են։