VPN ಗಾಗಿ ಮಾತ್ರ NGINX ಸೈಟ್: ಆಲಿಸುವವರು, ಫೈರ್‌ವಾಲ್ ಮತ್ತು HTTP ಅನುಮತಿ ಪಟ್ಟಿ

ಖಾಸಗಿ NGINX ಸೈಟ್‌ಗೆ ಬದ್ಧ VPN ಸಾಕೆಟ್, ಸೀಮಿತ ಹೋಸ್ಟ್ ಇನ್‌ಪುಟ್ ನಿಯಮ ಮತ್ತು ಅಖಂಡ HTTP ಪ್ರವೇಶ ಪಟ್ಟಿ ಬೇಕು. ಒಂದೇ ಸರ್ವರ್ ಬ್ಲಾಕ್ ಅಲ್ಲ, ಮೂರನ್ನೂ ಪರೀಕ್ಷಿಸಿ.

ಖಾಸಗಿ ಸೈಟ್ ಮತ್ತು ಇಂಟರ್ನೆಟ್ ನಡುವೆ ಮೂರು ಸ್ವತಂತ್ರ ನಿರ್ಣಯಗಳಿವೆ: ಯಾವ ಸಾಕೆಟ್ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಯಾವ ಮಾರ್ಗ ಅದನ್ನು ತಲುಪಿಸಬಹುದು, ಮತ್ತು ಆಯ್ಕೆಮಾಡಿದ ಸರ್ವರ್ ಯಾವ HTTP ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಸರ್ವರ್ ಬ್ಲಾಕ್ ಮೊದಲ ನಿರ್ಣಯವನ್ನು ಮಾತ್ರ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಉಳಿದ ಎರಡನ್ನು ಪ್ರತ್ಯೇಕ ನಿಯಂತ್ರಣಗಳಾಗಿ ಪರಿಗಣಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಸೈಟ್ ಖಾಸಗಿಯಾಗಿ ಕಾಣುತ್ತದೆ ಆದರೆ ಹಳೆಯ ಪ್ರವೇಶ ದ್ವಾರ ತೆರೆದೇ ಇರುತ್ತದೆ. VPN ಗಾಗಿ ಮಾತ್ರ ಇರುವ NGINX ವೈಫಲ್ಯಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಮೊದಲ ಪದರವನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸುವುದರಿಂದ ಬರುತ್ತವೆ.

ಉದಾಹರಣೆ tun0 ನಲ್ಲಿ 10.90.0.1 ನಲ್ಲಿ Linux OpenVPN ಗೇಟ್‌ವೇ, 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 ಬದಲಾವಣೆ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಸರಿಸಬಹುದು, ಮತ್ತು ನಾಲ್ಕು ಹೆಸರಿಸಿದ ಮೌಲ್ಯಗಳನ್ನು ಕೆಲಸ ಮಾಡುವ ಬ್ರೌಸರ್ ಟ್ಯಾಬ್‌ಗಿಂತ ಹೋಲಿಸುವುದು ಸುಲಭ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು