VPN NAT-ի հետևում, որը չեք կարող կարգավորել. ինչ դեռ աշխատում է

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

Քարտեզագրման աղյուսակը որոշում է ամեն ինչ

Ցանցային հասցեների փոխակերպումը պահում է աղյուսակ, որտեղ ներքին հասցեն ու պորտը գրանցվում են հանրային հասցեի ու պորտի դիմաց։ Գրառմանը համապատասխանող պատասխանները հետ են փոխակերպվում, իսկ դրսից եկող փաթեթը, որին համապատասխան գրառում չկա, ընդհանրապես նպատակակետ չունի։ Այդ մեկ վարքագիծը բացատրում է, թե ինչու երթուղիչի հետևի լսողը հասանելի չէ ինտերնետից։ Այն նաև բացատրում է, թե ինչու յուրաքանչյուր ուղղությամբ առաջին փաթեթը պետք է սկիզբ առնի ներսից։

Նայեք աղյուսակին երթուղիչի կողմից, և շրջանցումները ակնհայտ են դառնում՝ կա՛մ ինչ-որ բան ստեղծում է մշտական գրառում, կա՛մ ժամանակավոր գրառում է ստեղծում և պահում այն թարմ, կա՛մ երթևեկությունը ընդհանրապես չի գնում այդ ճանապարհով։ Հոդվածի մնացած մասը այդ երեք դեպքերն են հերթականությամբ։ Այստեղ ոչինչ կախված չէ մատակարարի այնպիսի ֆունկցիայից, որը դուրս է աղյուսակի գրանցածից։

Ինչ կարող է և ինչ չի կարող անել հանդիպման ծառայությունը

UDP անցքերի ծակումը օգտագործում է ելքային գրառումը որպես ժամանակավոր բացվածք՝ ֆիլտրը հաղթահարելու փոխարեն։ Երկու գործընկերներն էլ կապվում են հանդիպման ծառայության հետ, որը իմանում է յուրաքանչյուր հանրային վերջնակետ և վերադարձնում մյուս կողմին նրա վերջնակետը։ Այնուհետև երկուսն էլ ուղարկում են միմյանց ուղղությամբ, և յուրաքանչյուր ելքային փաթեթ ստեղծում կամ թարմացնում է այն գրառումը, որը ներս է թողնում պատասխանը։ Հերթականությունն է այն աշխատեցնում, և հերթականությունն է այն դարձնում փխրուն՝ գործընկերը, որը ուղարկում է մինչև մյուս կողմը ստեղծել է իր գրառումը, պարզապես դեն է նետվում, մինչդեռ մի պահ անց կրկնվող փորձը հաջողվում է։ Ծառայությունն ինքը VPN երթևեկություն չի կրում, ուստի նրա միակ լծակը համակարգվող ժամանակն է։

Քարտեզագրման վարքագիծը որոշում է մնացածը, և RFC 4787 անվանում է երեք ձևերը՝ վերջնակետից անկախ, հասցեից կախված, և հասցեից ու պորտից կախված։ Վերջինի դեպքում պորտը, որը գործընկերը պետք է թիրախավորի, փոխվում է յուրաքանչյուր նպատակակետի հետ, ուստի կանխատեսումը դադարում է հուսալի լինել։ Այստեղ է, որ տեխնիկան հանդիպում է իր փակուղուն, քանի որ օպերատորական մակարդակի NAT-ը և խիստ կորպորատիվ հրակայուն պատը երկուսն էլ հեռացնում են այն կանխատեսելիությունը, որն անհրաժեշտ է սխեմային, և կրկնությունների ոչ մի քանակ չի վերադարձնում այն։

Keepalive-ներ, վերագործարկումներ և շարժվող վերջնակետ

Ծակված ուղին հոսք է, ոչ թե լսող, ուստի ամեն ինչ, որ աշխատում է դրա վրա, պետք է դիմանա փոփոխությանը։ Այն պետք է պարբերական երթևեկությամբ կենդանի պահի քարտեզագրումը, նկատի, երբ հանրային վերջնակետը շարժվում է, և վերականգնվի երթուղիչի վերագործարկումից կամ հասցեի վերանշանակումից հետո։ Mesh VPN արտադրանքները այդ տրամաբանությունը դնում են իրենց կառավարման հարթությունում, մինչդեռ սովորական սերվերը այն թողնում է ձեզ։ Keepalive-ները օգնում են միայն այնքան ժամանակ, քանի դեռ նույն քարտեզագրումը գոյատևում է, և դրանք մարտկոց են ծախսում շարժական հաճախորդի վրա, ինչի պատճառով ագրեսիվ ինտերվալը անվճար չէ։

Մեկ ժամ քնած նոթբուքը սովորաբար վերադառնում է այլ հանրային վերջնակետի։ Ամեն ինչ, ինչ վերականգնում է ուղին, պետք է նորից աշխատի ներսից, ինչը նույն պահանջը վերադարձնում է հաճախորդին։

Երեք ուղի բացակայող փոխանցման շուրջ

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

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

Համապատասխանեցրեք շրջանցումը երթուղիչի սեփականատիրոջը

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

Նկատեք՝ արդյոք այն ուղին, որին հասաք, ուղիղ էր, թե ռելեով, քանի որ այս մեկ փաստը կանխատեսում է և՛ ուշացումը, և՛ ձախողման վարքագիծը։ RFC 4787-ը մնում է այդ ամենի ներքևում գտնվող քարտեզագրման վարքագծի հղումը, և նրա քարտեզագրման բաժինը կարդալն ավելի արագ է, քան երեք շրջանցում հաջորդաբար փորձարկելը։ Աղյուսակին չի հետաքրքրում, թե որ տարբերակն եք ընտրել, այն գրանցում է միայն, թե ինչ կարող է անել հաջորդ փաթեթը։