NGINX կայք միայն VPN-ի համար՝ լսող, հրմշտոց և HTTP թույլտվությունների ցանկ

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

Օրինակն օգտագործում է Linux OpenVPN դարպաս 10.90.0.1 հասցեով tun0-ի վրա, հաճախորդներ 10.90.0.0/24-ում, պահպանված աղբյուրներ և այս մուտքի համար վերապահված TCP 8443։ Կարգավորեք արժեքները, պահպանեք շերտերը։

Սկսեք սոկետից, ոչ թե հոսթի անունից

Կապեք HTTPS լսողը թունելի հասցեին և առանձին պորտին։ Կոնկրետ հասցեի մասին ավելի հեշտ է մտածել, քան ձևանմուշ սոկետի և անվան ստուգման մասին, քանի որ միջուկը պորտը չի տա այլ տեղական հասցեի։

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

Վկայագիրը պետք է պարունակի ծառայության հոսթի անունը, որը մուտքագրում են հաճախորդները, և մասնավոր DNS տեսքը պետք է լուծի այդ հոսթը կապված հասցեի։ server_name-ը միայն ընտրում է վիրտուալ հոսթ, այն ոչ ոքի չի նույնականացնում։ Բացակայող DNS գրառումը առաջացնում է վկայագրի սխալ, որը նման է TLS խափանմանը։ Ստուգեք անունը նախքան վկայագիրը փոխարինելը։

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

Փակեք այդ բովանդակության բոլոր այլ լսողները

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

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

Ստուգեք հասցեների երկու ընտանիքները։ IPv4 կապը անձեռնմխելի է թողնում IPv6 սոկետը, և նոր A գրառումը չի հետ կանչում հին AAAA պատասխանը, որը դեռ ցույց է տալիս հանրային ուղուն։

Հանեք հին վիրտուալ հոսթը որպես առանձին փոփոխություն։ Նոր բլոկի հանրային երկվորյակի հեռացումը սովորաբար այն քայլն է, որն իրականում փակում է մուտքը, մասնավոր լսողը միայն ավելացնում է նախատեսվածը։

Սահմանափակեք մուտքային ուղին հոսթում

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

Լռելյայն մերժող մուտքային քաղաքականությամբ և այս ծառայության համար ավելի լայն թույլտվության բացակայության դեպքում սահմանափակ կանոնը միասին նշում է թունելը, աղբյուրի միջակայքը, նպատակակետը և պորտը՝

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

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

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

Պահեք HTTP ցանկը անփոփոխ, երբ տեղերը փոխվում են

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

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

Վերանայեք յուրաքանչյուր տեղ, այլանուն և այլընտրանքային բլոկ որպես նույն քաղաքականության մաս։ Եթե IP ստուգումները համակցվում են NGINX նույնականացման հետ, հասկացեք satisfy-ը՝ any կարգավորումը կարող է հաճախորդին ներս թողնել մի մեխանիզմով, մինչ մյուսը չի անցել։ Դրեք մուտքի ցանկը տեղերի ստուգաթերթում։

HTTP մերժումը տեղի է ունենում այն բանից հետո, երբ TCP կապը հասնում է NGINX-ին։ Այն լրացնում է ցանցային սահմանափակումը, և հավելվածի սեփական լիազորումը դեռ գործում է յուրաքանչյուր օգտատիրոջ համար։

Ստուգեք կենդանի ուղին և խափանման դեպքը

Գործարկեք կարգավորումների վերլուծիչը, զննեք լսող սոկետները, ապա նախատեսված հաճախորդից արեք նոր անվանված հարցում։ Հաստատեք, որ վկայագիրը վավերանում է, DNS անունը լուծվում է կապված հասցեի, և պատասխանը գալիս է սպասված արմատից։

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

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

Գրանցեք սոկետը, պորտը, աղբյուրի միջակայքը և HTTP ցանկը, որոնք անցան։ Հաջորդ VPN կամ DNS փոփոխությունը կարող է տեղափոխել դրանցից ցանկացածը, և չորս անվանված արժեքներն ավելի հեշտ է համեմատել, քան աշխատող դիտարկիչի ներդիրը։