Կրկնակի NAT և ձեր VPN-ը. հաճախորդը աշխատում է, սերվերը՝ ոչ
Երկու երթուղիչ, որոնք թարգմանում են հասցեները, հազվադեպ են կանգնեցնում ելքային VPN հաճախորդին: Նրանց հետևում սերվեր տեղակայելն ավելի դժվար է, հատկապես երբ արտաքին շերտը օպերատորի մակարդակի NAT է:
Ձեր երթուղիչը կանգնած է մեկ այլ երթուղիչի հետևում, WAN հասցեն մասնավոր է, և VPN հաճախորդը միևնույն է միանում է: Այս համակցությունը զարմացնում է նրանց, ովքեր սպասում են, որ կրկնակի NAT-ը կկոտրի թունելները, բայց թարգմանությունը լավագույնս հենց ելքային կապերն է կառավարում: VPN սերվեր տեղակայելը նույն երկու շերտերի հետևում այն դեպքն է, որը սովորաբար ձախողվում է: Նախքան որևէ բան փոխելը գծեք կապի ուղղությունը:
Նախ գծեք կապի ուղղությունը
Բացեք ներքին երթուղիչի կարգավիճակի էջը և գրի առեք նրա WAN հասցեն, ապա համեմատեք այն հասցեի հետ, որը ձեզ հաղորդում է որևէ հանրային ծառայություն: Եթե երկուսը տարբերվում են, ձեր երթուղիչի և ինտերնետի միջև կա առնվազն մեկ թարգմանիչ: Եթե WAN հասցեն ընկնում է 100.64.0.0/10 միջակայքում, արտաքին թարգմանիչը հավանաբար ձեր մատակարարինն է, և դուք այն չեք վերահսկում: Այս երկու փաստերը որոշում են, թե հետագա քայլերից որն ընդհանրապես կարող է աշխատել:
curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1
Կրկնակի NAT-ը կրկնակի VPN չէ: Թարգմանությունը վերագրում է հասցեներ և պորտեր. այն չի ավելացնում երկրորդ գաղտնագրված թունել և ոչինչ չի գաղտնագրում: Այս երկու գաղափարներն առանձին պահելը կարևոր է, որովհետև լուծումները բոլորովին տարբեր են, և դրանցից մեկը պահանջում է զրույց ձեր մատակարարի հետ, այլ ոչ թե կարգավորումների էջ:
Ելքային ուղղություն. հաճախորդը հարցնում է, թարգմանիչները քարտեզագրում են
Ելքային թունելը սկսվում է ձեր մեքենայից եկող փաթեթով, ուստի յուրաքանչյուր թարգմանիչ կարող է քարտեզագրում ստեղծել և պատասխանը ներս թողնել: Արձանագրությունը, պորտը և անգործության ժամաչափերը որոշում են՝ այդ քարտեզագրումը բավական երկար կապրի՞ արդյոք օգտակար լինելու համար: Սպառողական երթուղիչների մեծ մասը դա լուծում է առանց որևէ կարգավորման:
Իսկապես ի հայտ եկող խափանումները սովորաբար վերաբերում են ժամանակի սպառմանը և արձանագրության աջակցությանը, այլ ոչ թե երթուղիչների քանակին: Մի քանի րոպե լռությունից հետո ընկնող թունելը ժամկետանցվող քարտեզագրում է, և keepalive-ը ստանդարտ պատասխանն է: IPsec-ն ունի ստանդարտ NAT-traversal ընդլայնումներ, ուստի այն պնդումը, թե այն չի կարող անցնել թարգմանության միջով, ուղղակի սխալ է: Եթե թունելն ընդհանրապես չի հաստատվում, նախքան տոպոլոգիային մեղադրելը նայեք վերջնակետին և հավատարմագրերին:
wg show
ping -c3 10.8.0.1
Կանգ առեք, եթե ելքային թունելը աշխատում է մի ցանցից և չի աշխատում մյուսից: Այդ համեմատությունը ցանցերի մասին է, ոչ թե երթուղիչների քանակի:
Մուտքային ուղղություն. փոխանցումը ծածկում է միայն ձեր սեփական սարքավորումը
Սերվեր տեղակայելը հակառակ ուղղությունն է. նոր կապ է գալիս ինտերնետից և պետք է հասնի ձեր մեքենային՝ անցնելով յուրաքանչյուր շերտով: Ներքին երթուղիչի պորտի փոխանցման կանոնը օգնում է միայն այն դեպքում, երբ արտաքին թարգմանիչը նույնպես այդ տրաֆիկը հասցնում է ձեզ: Տեղական կանոնը կրկնելը ձեզ չի տալիս մատակարարի սարքավորումների վերահսկողությունը:
nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'
Համեմատեք ներքին երթուղիչի WAN հասցեն ձեր դիտարկած հանրային հասցեի հետ և նշեք, թե որտեղից է եկել յուրաքանչյուր արժեք: Եթե WAN հասցեն մասնավոր է կամ ընդհանուր միջակայքում է, արտաքին շերտը կատարում է թարգմանություն, որը դուք չեք կարող կարգավորել: Նախքան ամբողջ երեկոն ուժի մեջ չմտնող կանոնների վրա ծախսելը հարցրեք մատակարարին, թե ինչ մուտքային հասանելիություն է աջակցում: Երթուղիչը հեռացնելը կամ հրդեհային պատնեշն ընդհանուր առմամբ անջատելը ախտորոշում չէ, և վատ փոխանակում է մեկ բաց պորտի համար:
Կանգ առեք, եթե արտաքին շերտը մատակարարինն է և այն չի փոխանցում: Այդ դեպքում աջակցվող պատասխաններն այլ մուտքի մեթոդ կամ ռելե են, այլ ոչ թե ևս մեկ կանոն ձեր կողմից:
Փորձարկեք մեկ փոփոխական միաժամանակ
Յուրաքանչյուր փորձարկման փոխեք մեկ բան և գրի առեք արդյունքը, որովհետև կրկնակի NAT ուղին ավելի շատ փոփոխականներ ունի, քան մեկ երթուղիչով ուղին: Պահեք պրոֆիլը և սարքը անփոփոխ, ապա համեմատեք այլ մուտքի ցանցի հետ: Նշեք՝ ձախողվում է բանակցությունը, թե ոչ, ընկնում է սեսիան անգործությունից հետո, թե ոչ, կամ միայն մասնավոր նպատակակետերն են ձախողվում: Այս երեք դիտարկումները մատնանշում են երեք տարբեր շերտեր:
journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40
Համընկնող մասնավոր ենթացանցերը առանձին թակարդ են, որը ոչ մի քանակի թարգմանություն չի ուղղում: Եթե ձեր տնային ցանցը և հեռավոր ցանցը օգտագործում են նույն միջակայքը, երթուղու կոնֆլիկտ է առաջանում անկախ նրանից, թե քանի թարգմանիչ կա միջև: Մի կողմի վերահամարակալումը միակ կայուն պատասխանն է:
Հեռավոր դարպասը նույն ուշադրությանն է արժանի, որովհետև նրա փոխանցման կանոնները և վերադարձի երթուղիները կարող են լինել բացակայող մասը: Նույնականացում անցած թունելը դեռ կարող է չունենալ օգտագործելի հավելվածային ուղի, և այդ խափանումը հաճախորդի կողմից նույն տեսքն ունի: Շրջայցն ավարտվում է, երբ կարող եք ասել, թե որ ուղղությունն է ձախողվում և որ շերտն է դրա պատասխանատուն: