Կարո՞ղ է թափառող VPN հաճախորդը սպասարկել գրասենյակի ծառայություն։

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

Զանգահարման ուղղությունը ոչինչ չի ասում ծառայության ուղղության մասին

Երբ հաճախորդը սկսում է թունել, այն բացում է ուղի, որն առաջանալուց հետո կարող են օգտագործել երկու ուղղությունները։ Թե նոր կապը կարո՞ղ է մուտք գործել կենտրոնից դեպի այդ հաճախորդը, դարպասի քաղաքականության հարց է, ոչ թե զանգահարողի հատկություն։ Օրինակ, երթուղավորված OpenVPN կենտրոնում սերվերին պետք է ուղի դեպի հաճախորդի ներքին հասցեն և փոխանցում, որը թույլ է տալիս հավասարակից հարաբերությունը։

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

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

Հետևեք պատասխանի ուղուն նախքան պորտ բացելը

Ուղին ունի երեք մաս՝ դարպասի վրա ուղի, որը ցույց է տալիս հաճախորդի ներքին հասցեն, քաղաքականություն, որը թույլ է տալիս կոնկրետ զանգահարողին, և լսող ծառայություն նշանակետում։ Յուրաքանչյուր մաս ձախողվում է տարբեր կերպ, դրա համար «VPN-ը միացած է» գրեթե ոչինչ չի ասում։

Լավ նորությունն այն է, որ ներքին ուղին չի պահանջում պորտի փոխանցում հաճախորդի տնային երթուղիչում։ Դա է ծառայությունը թունելի հասցեում հրապարակելու իմաստը՝ տնային WAN հասցեի փոխարեն, որտեղ բացահայտվածությունը և NAT կանոնները բոլորովին այլ կլինեին։ Տնային երթուղիչը կարող է նաև հրաժարվել գրասենյակից եկող կապի hairpin-ից, այնպես որ WAN ուղին ձախողվում է ձեր VPN-ի հետ կապ չունեցող պատճառներով։ Երթևեկությունը թունելի ներսում պահելը միանգամից խուսափում է երկու խնդրից։

Ստուգեք նաև նշանակետի կողմը։ Միայն 127.0.0.1-ին կապված ծառայությունը չի կարող ընդունել թունելի ինտերֆեյսով եկող կապը, որքան էլ դարպասի ուղիները ճիշտ լինեն։ Հոսթի firewall կանոնը, որը պորտը թույլ է տալիս միայն տեղական ենթացանցից, նույնպես կմերժի գրասենյակի երթևեկությունը, և այդ կանոնը անկախ է վերևի VPN քաղաքականությունից։

Անուններն ու հասցեները դիզայնի որոշումներ են

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

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

Համաձայնեցրեք անունը նրա հետ, ով տիրապետում է VPN ինքնությանը, որպեսզի գրառումը, հասցեի հատկացումը և մուտքի քաղաքականությունը փոխվեն միասին, ոչ թե երեք առանձին տոմսերով։

Փորձարկեք ծառայությունը, ոչ թե անդամակցությունը

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

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

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

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

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