Անջատիչ-արգելափակիչը կանգնեցնում է VPN սերվերը մինչև ցանկացած տրաֆիկի հոսքը
Որ փուլն է արգելափակում անջատիչ-արգելափակիչը՝ վերջնակետի որոնում, արտաքին երթուղի, վերադարձի ուղի և հնացած զուգընկերների բացառություններ — ենթադրությունների փոխարեն հաշվիչներով։
Անջատիչ-արգելափակիչները ձախողվում են մի ուղղությամբ, որ մարդիկ չեն սպասում՝ դրանք կառուցված են արգելափակելու տրաֆիկը, երբ թունելը իջեցված է, իսկ թունելը կառուցող փաթեթներն իրենք տրաֆիկ են։ Ամբողջ սխալը սա է։ Կանոնների հավաքածուն, որը դեն է նետում ամեն ինչ, ինչ դուրս չի գալիս թունելով, դեն է նետում նաև այն ձեռքսեղմումը, որը պետք է բարձրացներ այն, ուստի հաճախորդը կրկնում է փորձը օղակում, և սխալը վերագրվում է այն փուլին, որն առաջինն է ստուգվում։ Նախքան հրապատը լայնացնելը՝ պարզեք, թե երեք փուլերից որը մերժվում է՝ անվան որոնումը, զուգընկերոջը ուղղված արտաքին փաթեթը, թե վերադարձող պատասխանը։
Ինչպես են թունելը և նրա սեփական տրանսպորտը կախված միմյանցից
Կարդացեք VPN հաճախորդը որպես ցանցի երկու վիճակ, որոնք կիսում են մեկ սոկետի ուղի։ Մինչև թունելի գոյությունը հաճախորդը սոկետ է բացում ֆիզիկական ադապտերի վրա և գաղտնագրված շրջանակներ ուղարկում զուգընկերոջ հասցեին և պորտին։ Միայն այդ փոխանակության հաջողությունից հետո է նա ստեղծում թունելի սարքը և տեղադրում երթուղիները։ Անջատիչ-արգելափակիչը քաղաքականություն է երկրորդ վիճակի մասին՝ գրված այնքան լայն, որ վերաբերում է երկուսին։
Ինտերֆեյսի վրա հիմնված կանոնները սովորական ձևն են՝ ընդունեք այն, ինչ դուրս է գալիս tun0 կամ wg0-ով, դեն նետեք ելքի ուղու մնացածը։ Այդ ձևակերպումը չի կարող ազատել հաճախորդի սեփական կապը սերվերի հետ, ուստի ճիշտ իրականացումը այդ բացառությունը հստակ ավելացնում է, և դուք նույնպես, երբ ձեռքով կանոններ եք գրում։ Windows-ում և macOS-ում յուրաքանչյուր հավելվածի կանոնները շրջանցում են դրա մի մասը՝ ինտերֆեյսի փոխարեն պրոցես համապատասխանեցնելով, բայց պրոցեսը դեռ պետք է դուրս գա մինչև թունելի գոյությունը։
Երեք փուլ՝ այն հերթականությամբ, ինչպես որ պատահում են
Առաջին փուլը լուծումն է։ Երբ պրոֆիլը բառացի հասցեի փոխարեն պահում է հոսթի անուն, հաճախորդին անհրաժեշտ է DNS պատասխան՝ նախքան ինչ-որ բան ուղարկելը։ Պրոֆիլը, որը DNS-ը ուղղում է թունելի լուծիչին, փակուղի է ստեղծում՝ լուծիչը հասանելի է միայն այն թունելով, որը որոնումը պետք է հնարավոր դարձնի։ Թունելից դուրս լուծելը կամ վերջնակետը հասցեին ամրացնելը վերացնում է այդ երկիմաստությունը։
Երկրորդ փուլը արտաքին փաթեթն է, որը պետք է այս հերթականությամբ նախ դիմանա երթուղավորմանը, ապա հրապատին։ wireguard-tools-ը կատարում է դրա երթուղավորման կեսը WireGuard-ի համար՝ նշելով իր սեփական փաթեթները և ավելացնելով քաղաքականության կանոն, որպեսզի նրանք շրջանցեն հենց նոր տեղադրված լռելյայն երթուղին, մինչդեռ wg-quick-ի ձեռնարկի էջը նկարագրում է այդ կանոնը և այն աղյուսակը, որն այն օգտագործում է։ Վերակառուցեք այդ երթուղավորումը ձեռքով, կամ թույլ տվեք երկրորդ գործիքին վերաշարադրել կանոնները, և նշված փաթեթները կարող են հետ ուղարկվել այն թունել, որը նրանք պետք է ստեղծեն։
Երրորդ փուլը վերադարձի ուղին է։ Առանց պատասխանի ձեռքսեղմումը ելքի կողմից դեն նետելու ապացույց չէ, այն հավասարապես համահունչ է սերվերի մուտքային կանոնի կամ քարտեզագրումը մոռացած NAT սարքի հետ։ Առանձնացրեք դրանք նախքան հաճախորդին դիպչելը։
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Հաճախորդները գրանցում են հայտնաբերած ախտանիշը, ոչ թե ձախողված փուլը, ուստի աղյուսակը սովորաբար ավելի արագ է, քան մատյանը։
Հաշվիչները որոշում են ավելի արագ, քան մատյանները
Linux-ում՝ nft list ruleset կամ iptables -vnL OUTPUT տպում է փաթեթների հաշվիչ յուրաքանչյուր կանոնի համար։ Միացեք մեկ անգամ, թողեք ձախողվի, ապա նորից կարդացեք հաշվիչները։ Կանոնը, որի հաշվիչը շարժվել է, այն կանոնն է, որին դիպել է ձեռքսեղմումը, եթե ոչ մի տեղ ոչինչ չի շարժվել, փաթեթը երբեք չի հասել հրապատին։ Ես տեսել եմ, թե ինչպես կանոնների հավաքածուն դեն նետեց իր իսկ ձեռքսեղմումը, և դա ասացին միայն հաշվիչները։
Որպեսզի տարբերեք երբեք հրապատին չհասնելը երբեք հոսթից դուրս չգալուց, հետևեք ինքնին ինտերֆեյսին։ ip -s link show dev wlan0 հաղորդում է ուղարկված փաթեթների մասին, և tcpdump -ni wlan0 udp port 51820 ցույց է տալիս շրջանակները։ Եթե այն հարթ է մնում, մինչ հաճախորդը նորից փորձում է, անսարքությունը netfilter-ից վերև է՝ բացակայող զուգընկերոջ երթուղի, դեռ գոյություն չունեցող սարքին ուղղված քաղաքականության կանոն, կամ սոկետի սխալ, որը հաճախորդը կուլ է տալիս։
Փորձեք բացառությունները փաստաթղթային հասցեներով, օրինակ՝ 203.0.113.10, որպեսզի վրիպումը չկարողանա մեկ ուրիշի հոսթը ստուգել։
Հնացած վերջնակետի բացառությունը կարդացվում է որպես սերվերի անկում
Ամենապակողմնորոշիչ տարբերակը հայտնվում է այն բանից հետո, երբ զուգընկերոջ հասցեն փոխվել է՝ դինամիկ հասցեների ծառայությունը տեղափոխել է այն, հոսթը վերակառուցվել է, կամ ձեր ցանցի ելքային հասցեն տարբերվում է։ Բացառությունը դեռ նշում է հին հասցեն, ուստի նորին ուղղված փաթեթները հարվածում են դեն նետելու կանոնին։ Նույն կոնֆիգուրացիան երեկ աշխատում էր, և հենց դրա համար մարդիկ սկսում են սերվերի անսարքությունը որոնելուց։
Հրապատի կանոնի ներսում հոսթի անունը ձեզ չի փրկում։ nftables-ում անունը լուծվում է կանոնների հավաքածուն բեռնելիս, ուստի այն ամրացնում է այն հասցեն, որը գոյություն ուներ այդ պահին, և հնանում է բառացիի պես։ Կայուն լուծումը բացառությունը թարմացնելն է, երբ վերջնակետը փոխվում է, և այն նեղ պահելը՝ մեկ զուգընկերոջ հասցե, մեկ տրանսպորտային պորտ։ Հասցեի փոփոխությունը դիմանալու համար բավական լայն միջակայքը բավական լայն է նաև չկապված տրաֆիկը դուրս թողնելու համար։
Երբ անջատիչ-արգելափակիչը աշխատում է սերվերի հոսթի վրա
Նույն կախվածությունը գոյություն ունի նաև մյուս ծայրում, և այնտեղ այն ավելի հեշտ է բաց թողնել։ Եթե ձեր VPN սերվերի դերը կատարող մեքենան նաև աշխատեցնում է անջատիչ-արգելափակիչով աշխատասեղանի հաճախորդ կամ նոութբուքից պատճենված հրապատի պրոֆիլ, նրա դեն նետելու կանոնները վերաբերում են թունելներն ավարտող ծառայությանը։ Հաճախորդի ձեռքսեղմմանը տրվող պատասխանները դեն են նետվում, ուստի յուրաքանչյուր հաճախորդ չի կարողանում միանալ, մինչ սերվերը առողջ է թվում, և նրա թունելի ինտերֆեյսը մնում է չօգտագործված։
Այդ հոսթին պետք է երեք նեղ ընդունում մինչ դեն նետելը՝ լսելու պորտը ֆիզիկական ինտերֆեյսի վրա, թունելի ինտերֆեյսը վերծանված տրաֆիկի համար, և փոխանցումը թունելից դեպի այն, ինչին հաճախորդները պետք է հասնեն։ Կարդացեք տեղադրված հավաքածուն nft list ruleset, iptables -S, կամ pfctl -sr -ով՝ նախքան ինչ-որ բան փոխելը, և հիշեք, որ պահված կանոնների հավաքածուն վերապրում է վերագործարկումը, ուստի այնտեղի սխալը վերապրում է այն ստեղծած պրոցեսին։
Վերականգնման հերթականություն, որը մեքենան փակ է պահում
Աշխատեք պրոֆիլից դուրս։ Կարդացեք զուգընկերոջ հասցեն ու պորտը, որոնք օգտագործում է հաճախորդը, հաստատեք, որ հոսթի անունը լուծվում է առանց թունելի, ապա ավելացրեք մեկ բացառություն այդ հասցեի և պորտի համար միայն ֆիզիկական ադապտերի վրա։ Նորից միացեք և հետևեք ուղարկման հաշվիչին, ավարտված ձեռքսեղմումը նշանն է, որ երկրորդ փուլը վերանորոգված է։
Թողեք դեն նետելու մնացած քաղաքականությունը իր տեղում փորձարկման ընթացքում։ Անվնաս ստուգում է փորձել կապ չկապված փաստաթղթային հասցեի հետ և հաստատել, որ այն դեռ ժամկետը լրանում է, ինչը ցույց է տալիս, որ անջատիչ-արգելափակիչը աշխատում է, այլ ոչ թե անջատված։ Խստացրեք բացառությունը, երբ թունելը կայունանա, և չթողնեք մշտական ամեն ինչի թույլտվություն հաճախորդի ծրագրի համար միայն այն պատճառով, որ հարմար է։
Եթե թունելը բարձրանում է, և հավելվածը դեռ ձախողվում է, մնացած փուլերը սա չեն՝ բաժանված DNS-ը, MTU-ն և յուրաքանչյուր հավելվածի երթուղավորումը յուրաքանչյուրն ստեղծում է միացված թունել կոտրված տրաֆիկով, և յուրաքանչյուրն ունի տարբեր առաջին ստուգում։