Մեկ URL գրասենյակի և VPN-ի համար. ինչու է ձախողվում թույլատրվածների ցանկի առասպելը

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

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

Առասպելը. միանալը երթուղում չէ

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

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

Հարցման երեք վիճակ, երկու հաստատված ելք

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

Միջին տողն այն տեղն է, որտեղ կոտրվում են այս ծրագրերի մեծ մասը։ Կարևորը այն հասցեն է, որը տեսնում է պարտադրող սարքը, ոչ թե այն մասնավոր հասցեն, որը նոթբուքը պահում է թունելի ներսում, և ոչ էլ դրա LAN հասցեն։ 10.8.0.6-ի նման արժեքը ոչինչ չի նշանակում հանրային կայքի համար, և 192.168.1.44-ը նույնպես։ Թունելի հասցեն թունելի հասցեավորման մանրամասնություն է, ոչ թե վկայական, որը կայքը կարող է ստուգել։

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

Կարդացեք աղբյուրը այնտեղ, որտեղ որոշումն է կայացվում

Դրեք սահմանափակումը այն սարքի վրա, որը ավարտում է հարցումը, և հաստատեք, որ ոչ մի այլընտրանքային ծագման ուղի չի շրջանցում այն։ Nginx-ի մուտքի մոդուլ գնահատում է allow և deny հրահանգները հերթականությամբ, հաղթում է առաջին համընկնումը, և շրջապատող բլոկից ժառանգված կանոնները դեռ գործում են location-ի ներսում։ Նեղ allow-ը նույն տեղում լայն allow-ի կողքին սովորաբար նշանակում է, որ որոշում է լայնը։ Կարդացեք այդ location-ի ամբողջ գործող կարգաբերումը, նախքան դրա նույնիսկ մեկ տողը խմբագրելը։

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

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

Ապա ստուգեք հասցեների մյուս ընտանիքը։ Միայն IPv4-ը ընդգրկող կանոնների հավաքածուն թերի որոշում է այն հոսթանվան համար, որը պատասխանում է նաև AAAA-ով, և աշխատող IPv6 ունեցող հաճախորդը կհասնի նույն հավելվածին մի ուղիով, որը դուք երբեք չեք վերանայել։

Բաժանված թունել. հարցումը, որը երբեք չի մտնում

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

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

Ապացուցեք մերժումը, ապա՝ վերականգնումը

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

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

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

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