L2TP/IPsec-ը NAT-ի միջով. ինչ է իրականում կոտրվում և ինչու

Այն պնդումը, թե NAT-ը կոտրում է L2TP/IPsec-ը, կիսով չափ ճիշտ է և դրա համար անօգուտ։ Հասցեների թարգմանությունը նորմալ է, NAT traversal-ը գոյություն ունի հենց դա վերապրելու համար, և ամեն օր միլիոնավոր client-ներ միանում են router-ի հետևից։ Կոտրվում է կոնկրետ փոխանակման կոնկրետ փուլ. IKE-ը երբեք պատասխան չի ստանում, փաթեթավորված թունելը դեն է նետվում քաղաքականությամբ, որը թույլ է տալիս միայն մեկ protocol, կամ թարգմանության քարտեզագրումը սպառվում է, մինչ թունելը անգործ է։ Երբ իմանաք, թե որ փուլում եք, լուծումը սովորաբար մեկ կանոն կամ keepalive է, ոչ թե VPN-ի նոր ձևավորում։

Առասպելը սխալ հարցն է

Օգտակար հարցը ոչ թե «NAT-ը կոտրու՞մ է սա» է, այլ «փոխանակման ո՞ր մասն է թարգմանվում, և ինչ է անում դրա հետ թարգմանող սարքը»։ L2TP/IPsec-ը շերտավոր protocol է. IKE-ը բանակցում է, ESP-ը պաշտպանում է, և L2TP այդ պաշտպանության ներսում տեղափոխում է PPP։ Հասցեների թարգմանությունը տարբեր կերպ է ազդում յուրաքանչյուր շերտի վրա, և ձախողման ստորագրությունները կարելի է տարբերել, եթե նայեք բանակցության փուլին, ոչ թե սխալի երկխոսությանը։

Հաջողությամբ վեբ զննող router-ը միայն ապացուցում է, որ TCP-ն՝ աղբյուր port-ի թարգմանությամբ, աշխատում է։ Այն ոչինչ չի ասում UDP 500-ի, UDP 4500-ի կամ 50 protocol-ի մասին, և այս տեղադրումը կախված է հենց այդ երեքից։

Փուլ 1. IKE-ը պետք է ընդհանրապես պատասխան ստանա

Առաջին փոխանակումը գնում է պատասխանողին UDP 500-ով։ Եթե պատասխան չվերադառնա, մնացած ամեն ինչ նշանակություն չունի. նախապես համօգտագործված բանալին, առաջարկը և հավատարմագրերը մնում են չկարդացված։ Հետևեք հարցմանն ու պատասխանին, փոխանակ client-ի timeout-ից եզրակացնեք:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Առանց պատասխանի հարցումը սովորաբար նշանակում է, որ firewall-ը կամ վերևի օպերատորը դեն է նետում packet-ը, ոչ թե server-ը մերժել է այն։ Ծանուցման բեռով պատասխանը, որը նշում է առաջարկ կամ վկայագրի խնդիր, նշանակում է, որ packet-ները հասել են, և բանակցությունը ձախողվել է բովանդակության պատճառով, ինչը բոլորովին այլ վերանորոգում է։

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

Փուլ 2. փաթեթավորումը փոխում է այն, ինչ տեսնում է firewall-ը

ESP-ը IP protocol է, ոչ TCP կամ UDP port, և սովորական port-հասցեի թարգմանությունը port-ի դաշտ չունի, որ վերագրի։ Դրա համար NAT traversal-ը պաշտպանված բեռը տեղափոխում է UDP 4500. փաթեթավորումը թարգմանող սարքին տալիս է մի բան, որը նա գիտի ինչպես թարգմանել։ Երբ դա տեղի ունենա, միայն UDP 500-ի համար գրված firewall-ի կանոնը թույլ կտա բանակցությունը և կնետի թունելը, ինչը տալիս է շփոթեցնող արդյունք, երբ մատյանը ցույց է տալիս հաջող 1-ին փուլ և ոչ մի երթևեկություն։

Ինքը IKE փոխանակումը նույնպես կարող է տեղափոխվել UDP 4500՝ NAT-ի հայտնաբերումից հետո, ինչը զարմացնում է նրանց, ովքեր թույլ են տվել 500 և ուրիշ ոչինչ։ Թույլ տվեք երկու port-ներն էլ երկու ուղղություններով ուղու վրա, և հիշեք, որ վիճակով firewall-ը կարող է պահել հոսքը միայն այնքան, քանի դեռ տեսնում է երթևեկություն։

50 protocol-ը դեռևս կարևոր է առանց թարգմանության ուղիներում և այն ուղիներում, որտեղ միջանկյալ տուփը կարգավորված է այն թույլ տալու համար։ Եթե ախտորոշում եք բացառմամբ, անջատեք վարկածը՝ կանոնները խմբով ավելացնելու փոխարեն. թույլ տվեք 500, 4500 և ESP, հաստատեք, որ թունելը բարձրանում է, ապա հեռացրեք այն, ինչ ավելորդ է ստացվել։ Կանոնը, որը ոչ ոք չի կարող բացատրել, այն կանոնն է, որը ոչ ոք չի հեռացնի, երբ այն դառնա հաջորդ ընդհատման պատճառը։ Գրեք նեղացումը փոփոխությունների մատյանում՝ դրա ուղղած փուլի հետ միասին, որպեսզի հաջորդ ինժեները սկսի ձեր ապացույցներից, ոչ թե նույն բթամատի կանոնից։

Փուլ 3. քարտեզագրումը սպառվում է, և թունելը մահանում է

Թարգմանող սարքը վիճակ է պահում այն հոսքերի համար, որոնք փոխանցում է, և այդ վիճակն ունի կյանքի տևողություն։ L2TP/IPsec թունելը քիչ երթևեկություն է տեղափոխում, երբ ոչ ոք չի օգտագործում այն, ուստի անգործ թունելը կարող է վերապրել իր քարտեզագրումը և դադարել ստանալ վերադարձի երթևեկություն։ Client-ը մնում է համոզված, որ միացած է, server-ը ոչինչ չի տեսնում, և առաջին ախտանիշը սովորաբար հավելվածի timeout-ն է, ոչ թե VPN-ի սխալը։

Մեռած զուգընկերոջ հայտնաբերումը և NAT-ի keepalive-ները հենց դրա համար են, և երկու ծայրերը պետք է պատրաստ լինեն դրանք ուղարկել։ Եթե ձեր server-ը թարգմանության հետևում է, Windows-ի կողմի պահանջը փաստագրված գրանցամատյանի կարգավորում է, որը server-ին ստիպում է իր արտագնա packet-ների համար ենթադրել UDP փաթեթավորում. առանց դրա պատասխանողը ուղարկում է ESP, որը թարգմանող սարքը չի կարող հետ քարտեզագրել։ Սա server-ի կարգավորման հարց է, ոչ client-ի։

WAN-ի հասցեի փոփոխությունը նույն արդյունքն է տալիս մյուս կողմից. քարտեզագրումը վերակառուցվում է նոր հասցեի շուրջ, և հին անվտանգության ասոցիացիան այժմ մատնանշում է մի զույգի, որն այլևս գոյություն չունի։ Վերամիացման վարքը պատկանում է client-ի իրականացմանը, և դրա համար «վերամիացիր router-ի վերագործարկումից հետո» աշխատում է մի client-ի վրա և մյուսի վրա պահանջում է ձեռքով անջատիչ։

Օպերատորի մակարդակի NAT-ի հետևում հոսթինգը այլ խնդիր է

Եթե ցանկանում եք տանը հոսթել L2TP/IPsec server և դրսից հասնել դրան, պահանջը չպահանջված մուտքային հասանելիությունն է, և դա այն չէ, ինչ տալիս է NAT traversal-ը։ Ձեր router-ի առջև օպերատորի մակարդակի NAT-ը նշանակում է, որ չկա port, որը կարող եք փոխանցել և դառնալ հասանելի, քանի որ հանրային հասցեն համօգտագործվում է, և քարտեզագրումը միայն արտագնա է։

Ոչ մի IPsec pass-through վանդակ չի փոխում դա, և client-ի ոչ մի կարգավորում չի փոխհատուցում այն։ Աջակցվող պատասխաններն են իսկապես հասանելի հասցեն, հոսթավորված վերջնակետը, կամ ճարտարապետություն, որտեղ յուրաքանչյուր մասնակից արտագնա կապ է հաստատում։ UDP փաթեթավորման սպեցիֆիկացիան լուծում է թարգմանության խնդիրը գոյություն ունեցող հոսքերի համար. այն մուտքային ուղի չի ստեղծում այնտեղ, որտեղ օպերատորը չի առաջարկում։

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