Yalnız VPN üçün NGINX saytı: dinləyici, firewall və HTTP icazə siyahısı

Şəxsi saytla internet arasında üç müstəqil qərar dayanır: hansı soket bağlantını qəbul edir, hansı yol onu çatdıra bilər və seçilmiş server hansı HTTP müştərilərinə cavab verir. Server bloku yalnız birinci qərarı verir. Digər ikisinə ayrı nəzarətlər kimi yanaşın, əks halda sayt şəxsi görünəcək, köhnə giriş isə açıq qalacaq. Yalnız VPN üçün NGINX uğursuzluqlarının çoxu yalnız birinci qatı sınamaqdan gəlir.

İşlənmiş nümunə tun0 üzərində 10.90.0.1 ünvanında Linux OpenVPN şlüzündən, 10.90.0.0/24 şəbəkəsindəki müştərilərdən, qorunan mənbələrdən və bu giriş üçün ayrılmış TCP 8443 portundan istifadə edir. Dəyərləri uyğunlaşdırın, qatları saxlayın.

Host adı ilə deyil, soketlə başlayın

HTTPS dinləyicisini tunel ünvanına və ayrı porta bağlayın. Konkret ünvan, wildcard soket və ad yoxlaması birləşməsindən daha asan düşünülür, çünki nüvə portu başqa yerli ünvana verməyəcək.

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;
    }
}

Sertifikat müştərilərin yazdığı xidmət host adını göstərməlidir və şəxsi DNS görünüşü həmin hostu bağlanmış ünvana həll etməlidir. server_name yalnız virtual host seçir; heç kimi autentifikasiya etmir. Çatışmayan DNS qeydi TLS nasazlığına bənzəyən sertifikat xətası yaradır. Sertifikatı dəyişməzdən əvvəl adı yoxlayın.

Faylı əlavə etməzdən əvvəl effektiv konfiqurasiyanı oxuyun. Daxiletmələr və wildcard dinləyicilər eyni kökü başqa yerdə təqdim edə bilər və defolt server yeni blokun heç görmədiyi sorğulara cavab verə bilər.

Həmin məzmun üçün bütün digər dinləyiciləri bağlayın

listen direktivlərini siyahıya alın və onların təqdim etdiyi kökləri müqayisə edin. Başqa tətbiq üçün əlavə edilmiş blok eyni upstream-ə proxy edə bilər və köhnə defolt server yeni blok yerində olsa da cavab verməyə davam edə bilər. Həmin çıxış əsl inventardır, indicə redaktə etdiyiniz fayl deyil. Eyni məzmunu təqdim edən hər kökü müqayisə edin.

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

Hər iki ünvan ailəsini yoxlayın. IPv4 bağlanması IPv6 soketini toxunulmaz qoyur və yeni A qeydi hələ də publik yola işarə edən köhnə AAAA cavabını ləğv etmir.

Köhnə virtual hostu ayrı dəyişiklik kimi dayandırın. Yeni blokun publik əkizini silmək adətən girişi həqiqətən bağlayan addımdır; şəxsi dinləyici yalnız nəzərdə tutulan girişi əlavə edir.

Daxil olan yolu hostda məhdudlaşdırın

Dinləmə ünvanı giriş interfeysini deyil, soketi məhdudlaşdırır. Başqa yerdən həmin ünvana yönləndirilən paket yenə yerli giriş kimi gəlir, ona görə host firewall-unun bağlantının haradan gələ biləcəyi barədə öz bəyanatı lazımdır. Buna görə tək bağlama audit tələbini nadir hallarda ödəyir.

Defolt rədd giriş siyasəti və bu xidmət üçün geniş icazə olmadıqda, məhdud qayda tuneli, mənbə aralığını, təyinatı və portu birlikdə adlandırır:

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

Tətbiq etməzdən əvvəl effektiv firewall sırasını oxuyun. Əvvəlki geniş qəbul məhdudiyyəti poza bilər, əvvəlki terminal drop isə bu icazəyə heç vaxt çatmağa imkan verməyə bilər. Nümunə uyğun olsun deyə əlaqəsiz qaydaları təmizləməyin və firewall-u söndürməyin.

Həmin qayda host girişidir, başqa LAN maşınına marşrut deyil və şlüzün xarici OpenVPN dinləyicisi ayrı xidmət olaraq qalır. Sayt əvvəllər publik idisə, köhnə girişin necə dayandırılacağını və mövcud sessiyaların necə idarə olunacağını planlaşdırın.

Yerlər dəyişdikcə HTTP siyahısını bütöv saxlayın

NGINX allow və deny girişlərini sıra ilə qiymətləndirir və yuxarıdakı server səviyyəli siyahı son deny-dan əvvəl elan edilmiş hovuzu qəbul edir. Giriş modulu həmçinin qeyd edir ki, hər hansı giriş elementi təyin edən yer öz siyahısından istifadə edir, ana siyahıdan deyil. Sıra girişlərin özü qədər vacibdir.

Bu sıfırlama adi reqressiyadır. Bir giriş əlavə edən yeni yükləmə, API və ya sağlamlıq yeri server səviyyəli məhdudiyyəti səssizcə əvəz edir və sayt ən son əlavə edilmiş yolda genişlənir.

Hər yeri, alias-ı və alternativ bloku eyni siyasətin hissəsi kimi nəzərdən keçirin. IP yoxlamaları NGINX autentifikasiyası ilə birləşdirilirsə, satisfy-ı anlayın: any parametri müştərini bir mexanizmlə buraxa bilər, digəri isə hələ keçməmiş ola bilər. Giriş siyahısını yer yoxlama siyahısına daxil edin.

HTTP rəddi TCP bağlantısı NGINX-ə çatdıqdan sonra baş verir. O, şəbəkə məhdudiyyətini tamamlayır və tətbiqin öz avtorizasiyası hər istifadəçiyə hələ də tətbiq olunur.

Canlı yolu və uğursuzluq halını yoxlayın

Konfiqurasiya analizatorunu işə salın, dinləyən soketləri yoxlayın, sonra nəzərdə tutulan müştəridən təzə adlı sorğu edin. Sertifikatın doğrulandığını, DNS adının bağlanmış ünvana həll olunduğunu və cavabın gözlənilən kökdən gəldiyini təsdiqləyin.

Sonra kənarlaşdırılmış mənbəyi və alternativ girişi sınayın. İşləyən icazəli sorğu bağlamaq istədiyiniz yollar barədə heç nə demir və kənarlaşdırılmış sınaq qalıq dinləyicinin və ya geniş firewall qəbulunun göründüyü yerdir.

Yükləmə və ya VPN bərpası halını təkrarlayın. NGINX tunel ünvanı mövcud olmadan əvvəl başlayırsa, bağlama mükəmməl faylla belə uğursuz ola bilər. Ünvan hazırlığını əlaqələndirin və paylaşılan veb serveri dəyişməzdən əvvəl yerli bərpa yolu saxlayın.

Keçən soketi, portu, mənbə aralığını və HTTP siyahısını qeyd edin. Növbəti VPN və ya DNS dəyişikliyi onlardan hər hansı birini dəyişə bilər və dörd adlandırılmış dəyəri müqayisə etmək işləyən brauzer sekmesinden asandır.