VPN-ը միացած է, բայց ֆայրվոլը դեռ արգելափակում է. ինչպես հասկանալ, թե որն է

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

Առանձնացրեք ուղին քաղաքականությունից

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

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

Կարդացեք ուղին մեկ անցումով

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

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

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

Կարդացեք քաղաքականությունը այն շերտում, որը պատասխանում է

Երբ ուղին ճիշտ է, անցեք քաղաքականությամբ հոսթից դուրս և հետևեք այն մեկ շերտին, որի հաշվիչները շարժվում են:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Լսող սոքեթը պատասխանում է այլ հարցի, քան կանոնները։ Եթե պորտի վրա ոչինչ չի լսում, միջուկը մերժում է միացումը, և ոչ մի ներգնա կանոն տեղին չէ։ Եթե սոքեթը կա, և հեռավոր հաճախորդից միացումը ժամկետանց է, դեն նետում տեղի է ունենում ուղու ինչ-որ տեղում, և կանոնների հաշվիչները ասում են՝ այստե՞ղ է դա։

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

Կարդացեք դարպասի որոշումը, երբ թունելը այնտեղ է ավարտվում

Կայք-կայք կամ հեռավոր մուտքի դարպասում VPN-ը նույնականացնում է օգտատիրոջը, իսկ քաղաքականությունը լիազորում է ռեսուրսը, և դրանք առանձին թույլտվություններ են։ Թունել մուտք գործած օգտատերը ավտոմատ կերպով չի մուտք ստանում յուրաքանչյուր ներքին հոսթ, և մերժումը հաճախ գալիս է փոխանցման կանոնից, մինչ ինքը թունելը առողջ է։ Նույն բաժանումը երևում է IPsec-ում, որտեղ թրաֆիկը ընտրող անվտանգության քաղաքականությունը տարբերվում է այն ընդունող զտիչից, և դրա համար էլ երկուսը փաստաթղթավորված են որպես տարբեր մեխանիզմներ RFC 4301։

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

Դարպասն այն տեղն է նաև, որտեղ NAT-ի կամ քողարկման կանոնը կարող է թաքցնել իրական աղբյուրը։ Եթե ներքին հոսթերը տեսնում են դարպասի հասցեն՝ հաճախորդի փոխարեն, ապա նրանց հոսթի ֆայրվոլի կանոնները, որոնք պետք է համընկնեն հաճախորդների լողավազանի հետ, երբեք չեն համընկնի, և ուղղումը դարպասինն է, ոչ յուրաքանչյուր սերվերինը։

Փոխեք ամենանեղ շերտը, ապա ստուգեք

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

Ստուգեք նույն փորձությամբ, որը ձախողվեց, նույն հաճախորդից, ապա ևս մեկ անգամ վերամիանալուց հետո, որովհետև կանոնը, որը համընկնում էր մինչև թունելի նոր բանակցությունը, կարող է դրանից հետո դադարել համընկնել:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Նախքան այն փակելը:

• Ուղին դեպի նպատակակետ դուրս է գալիս թունելի ինտերֆեյսով, և աղբյուրի հասցեն համապատասխանում է նրան, ինչ սպասում է քաղաքականությունը։
• Ինչ-որ բան լսում է պորտի վրա, և մերժումը կամ ժամկետը վերագրվում է անվանված կանոնի, ոչ ենթադրվում։
• Դարպասը փոխանցում է երկու ուղղությամբ, և նպատակակետը տեսնում է այն աղբյուրը, որի համար գրվել են ձեր կանոնները։
• Ոչ մի հսկիչ չի անջատվել, որպեսզի փորձությունը անցնի, և ձեր արած փոփոխությունը նշում է մեկ աղբյուրի տիրույթ և մեկ պորտ։