VPN դարպասին անհրաժեշտ է IP փոխանցում՝ ինչ ստուգել

Ձեր հաճախորդը կարող է ping ուղարկել դարպասի հասցեին, մինչ դրա ետևում գտնվող բոլոր ռեսուրսները մնում են անհասանելի։ Այս երկու դիտարկումները նկարագրում են հոսթ, որը խոսում է ձեզ հետ, և երթուղիչ, որը չի երթուղավորում, ինչը տարբեր դերեր են նույն մեքենայի վրա։ Փոխանցումը նրանց միջև անջատիչն է։

Երկու դերերը անկախ են, ինչպես և երկու հասցեային ընտանիքները։

Սեփական հասցեին պատասխանելը ոչինչ չի ապացուցում

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

Կարդացեք պահանջը որպես դեր, ոչ որպես կարգավորում. այս հոսթը պետք է փաթեթներ տեղափոխի երկու միջերեսների միջև։ Նոութբուքը, որին պետք է միայն հեռավոր ցանց հասնել, երբեք չի վերցնում այդ դերը, իսկ կայք-կայք վերջնակետը միշտ վերցնում է։ Պահանջը այսպես կարդալը բացատրում է, թե ինչու աշխատող հաճախորդի կազմաձևը ձախողվում է դարպաս տեղափոխելիս։

Նույն նախադասությունը վերաբերում է փոխանցման որոշման դիմացի պատնեշին, որն ունի իր քաղաքականությունը, թե ինչ կարելի է փոխանցել։

Ստուգեք յուրաքանչյուր հասցեային ընտանիքը առանձին

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

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

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

Փոխանցումը չորս պահանջներից մեկն է

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

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

Փորձարկեք հաճախորդից, ոչ դարպասից

Դարպասի սեփական shell-ում անցկացված փորձարկումը չի անցնում այն փոխանցման ուղու ոչ մի հատվածով, որը դուք հենց նոր միացրիք։ Առաջացրեք երթևեկությունը խնդիր ունեցող հաճախորդից և հաստատեք, որ այն հասնում է դարպասի ետևի ինչ-որ բանի, այլ ոչ թե հենց դարպասին։ Սա միակ փորձարկումն է, որը վարժեցնում է ձեր փոխած դերը։

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

Եթե փաթեթները հասնում են, և ծառայությունն այնուհետև մերժում է օգտատիրոջը, դուք անցել եք ցանցային մակարդակից։ Շարունակեք հավելվածի լիազորումով՝ փոխանցման քաղաքականությունը կրկին ընդլայնելու փոխարեն։