Ինչու GRE-ը և ESP-ը ձախողվում են AWS NAT-դարպասով

Թունելը ձախողվում է, անվտանգության խումբն արդեն թույլատրում է ողջ երթևեկությունը, և եզրակացվում է, որ AWS-ը արգելափակում է VPN-ը։ Այն ոչինչ չի արգելափակում։ Կառավարվող NAT-դարպասը փոխանցում է արտաքին արձանագրությունների փաստաթղթավորված հավաքածու, և բնիկ GRE-ը կամ բնիկ ESP-ը դրա մեջ չեն, ուստի ձեր ավելացրած ոչ մի կանոն չի ստիպի դարպասին տեղափոխել դրանք։ Թույլտվության կանոնը և տեղափոխման ունակությունը երկու տարբեր բաներ են, և դրանցից միայն մեկն է ձեր փոխելու տիրույթում։

Կանոնների հավաքածուն արձանագրությունների հավաքածուն չէ

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

AWS-ի NAT-դարպասի արձանագրությունների ճշգրտումը թվարկում է TCP, UDP և ICMP կառավարվող ծառայության համար։ Դա ամբողջ աջակցվող հավաքածուն է։ Այլ IP արձանագրության համար թույլտվության կանոնը չի կարող ընդլայնել այն, քանի որ կանոնը գնահատվում է շատ ավելի վաղ, քան հասնում են դարպասի փոխանցման ուղուն։

Տարբերությունը կարևոր է, քանի որ երկու ձախողումները հաճախորդի կողմից նույն տեսքն ունեն և բոլորովին տարբեր ուղղումներ ունեն։

PPTP-ն ցույց է տալիս, թե ինչու պորտի թեստը ստում է

PPTP-ն պորտի ստուգման ամենապարզ հին օրինակն է, որն ոչինչ չի ապացուցում։ Այն բացում է TCP կառավարման կապակցում 1723 պորտի վրա և այնուհետև թունելի տվյալները տեղափոխում GRE-ով, որը IP արձանագրություն 47-ն է։ 47 արձանագրությունը TCP 47 պորտ չէ, և այդ երկու թվերը ոչ մի կապ չունեն միմյանց հետ բացի թվանշաններ կիսելուց։

Օպերատորը, ով ստուգում է կապը 1723-ի հետ և տեսնում ավարտված ձեռքսեղմում, եզրակացնում է, որ ուղին աշխատում է։ Այնուհետև տվյալների ալիքը երբեք չի անցնում ոչ մի փաթեթ, քանի որ դարպասը GRE աջակցություն չունի առաջարկելու։ Սա հին արձանագրության պահանջների մեկնաբանություն է, ոչ թե PPTP տեղակայելու խորհուրդ, որը տարիներ շարունակ հնացած է։

Նույն տրամաբանությունը վերաբերում է ցանկացած արձանագրության, որի կառավարման ալիքը TCP կամ UDP է, մինչդեռ տվյալների ուղին այդպիսին չէ։

IPsec-ը գոյատևում է միայն որպես UDP

IPsec-ը այն դեպքն է, երբ պատասխանը պայմանական է, այլ ոչ թե հստակ ոչ։ AWS-ը փաստաթղթավորում է NAT-ի անցումը որպես աջակցվող կարգավորում NAT-դարպասով IPsec-ի համար։ NAT-T-ի շուրջ պայմանավորվածությամբ ESP-ը փաթեթավորվում է UDP-ի մեջ, և դարպասը տեսնում է սովորական UDP՝ 50 արձանագրության փոխարեն։

UDP 4500-ի թույլտվությունը չի ստիպում ծայրակետերին օգտագործել NAT-ի անցում։ Այն թույլատրում է փաթեթները միայն այն դեպքում, եթե դրանք արդեն այդ ձևով են։ Հաստատեք հաճախորդի սեփական բանակցության արդյունքից, թե որ փաթեթավորումն է ընտրվել, և հաստատեք ընդունող կողմում, որ գործընկերը ընդունել է այն։ Բնիկ ESP-ի համար կարգավորված երկու ծայրակետեր կշարունակեն ուղարկել բնիկ ESP՝ անկախ նրանից, թե ինչ է ասում կանոնների հավաքածուն։

TCP- կամ UDP-հիմք VPN-ը տեղավորվում է փաստաթղթավորված տեղափոխման հավաքածուի մեջ և այնուամենայնիվ կարող է ձախողվել երթուղավորման, զտման կամ նույնականացման պատճառներով։ Հավաքածուին տեղավորվելը անհրաժեշտ է, բայց ոչ բավարար։

Ստուգեք ուղին նախքան քաղաքականությունը լայնացնելը

Ստուգեք աշխատանքային ծանրաբեռնվածության ենթացանցի իրական երթուղին և նրա հաջորդ ցատկի ինքնությունը նախ։ Ուղիղ հանրային ուղին, NAT ինստանսը, կառավարվող NAT-դարպասը և տրանզիտ դարպասով մասնավոր ուղին չորս տարբեր ձևավորումներ են, և դրանցից միայն մեկն է այստեղ նկարագրված կառավարվող ծառայությունը։

Այնուհետև գրանցեք փորձված ծայրակետը, հասցեների ընտանիքը, արտաքին արձանագրությունը և պորտը, որտեղ արձանագրությունը ունի այդպիսին։ Օգտագործեք հաճախորդի ախտորոշումը և ցանցի սեփականատիրոջ հոսքի դիտարկումները՝ հաջողված զննարկիչի հարցման փոխարեն, որը միայն ապացուցում է, որ TCP-ն և UDP-ն աշխատում են։ Դրանից հետո վերանայեք անվտանգության խումբը, ենթացանցի ACL-ը, հյուրի firewall-ը և ծառայության քաղաքականությունը հոսքի երկու ուղղությունների համար։

Մի բացեք ողջ երթևեկությունը՝ փոխհատուցելու այն տեղափոխումը, որը ծառայությունը չի կարող տանել։ Կանոնի փոփոխությունը չի շտկի դա, և այն կփրկվի միջադեպից։

Երբ տեղափոխումը չի տեղավորվում

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

Մուտքային VPN սերվեր հյուրընկալելը առանձին պատասխանով առանձին խնդիր է։ NAT-դարպասը տրամադրում է ելքային թարգմանություն և ընդհանուր մուտքային պորտերի փոխանցում չի տրամադրում, ուստի դրա հետևում գտնվող սերվերը կարիք ունի իր հաստատված հանրային մուտքի, որը նախագծված է իր պայմաններով։

Աշխատանքի կարգը՝ անվանեք արտաքին արձանագրությունը, հաստատեք հաջորդ ցատկը, համեմատեք այն փաստաթղթավորված հավաքածուի հետ, ապա փոխեք ճարտարապետությունը կամ տեղափոխումը։ Այլ պորտի համարը չի կարող GRE-ն դարձնել TCP, և ևս մեկ թույլատրող կանոն չի կարող ավարտված կառավարման փոխանակումը դարձնել աշխատող տվյալների ալիք։