ಮುಂದೆ Nginx, VPN ಹಿಂದೆ ಖಾಸಗಿ ಬ್ಯಾಕೆಂಡ್

ರೈಲಿನಲ್ಲಿರುವ ಫೋನ್‌ನಿಂದ ಒಂದು ವಿನಂತಿಯನ್ನು ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್ ಒಳಗೆ ಮಾತ್ರ ಇರುವ ಬ್ಯಾಕೆಂಡ್‌ವರೆಗೆ ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. ಫೋನ್ ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಪೋರ್ಟ್ 443 ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ. Nginx ಆ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ನಂತರ VPN ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ಮಾತ್ರ ತಲುಪುವ ವಿಳಾಸಕ್ಕೆ ಎರಡನೇ, ಸಂಪೂರ್ಣ ಪ್ರತ್ಯೇಕ ಸಂಪರ್ಕ ತೆರೆಯುತ್ತದೆ. ಫೋನ್‌ನಲ್ಲಿ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಸುರಂಗ ಒಳಗೊಂಡಿತ್ತು ಎಂದು ಫೋನ್‌ಗೆ ಎಂದಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ.

ಒಂದು ವಿನಂತಿಯನ್ನು ಎರಡು ಸಂಪರ್ಕಗಳ ಮೂಲಕ ಅನುಸರಿಸುವುದು

ಒಳಬರುವ ಭಾಗ ಒಂದು ಸಾರ್ವಜನಿಕ HTTP ವಹಿವಾಟು. ಅದಕ್ಕೆ ಸಾರ್ವಜನಿಕ ಹೆಸರು, ಸಾರ್ವಜನಿಕ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಆ ಕ್ಷಣದಲ್ಲಿ ಸಂದರ್ಶಕನ ಬಳಿ ಇರುವ ಯಾವುದೇ ವಿಳಾಸಕ್ಕೂ ಕೆಲಸ ಮಾಡಬೇಕಾದ ಪ್ರತಿಕ್ರಿಯೆ ಮಾರ್ಗ ಇವೆ. ಆ ಮಾರ್ಗವನ್ನು ಕೆಡಿಸುವ ಯಾವುದೇ ಬದಲಾವಣೆ ಎಲ್ಲಾ ಸಂದರ್ಶಕರನ್ನು ಒಂದೇ ಬಾರಿಗೆ ಮುರಿಯುತ್ತದೆ. ಆದ್ದರಿಂದ ಸಾರ್ವಜನಿಕ ಭಾಗ ನೀವು ಅತಿ ಕಡಿಮೆ ಪ್ರಯೋಗ ಮಾಡಲು ಬಯಸುವ ಭಾಗ.

ಹೊರಹೋಗುವ ಭಾಗ ಖಾಸಗಿ. Nginx ಕ್ಲೈಂಟ್ ಆಗುತ್ತದೆ, ಒಳಗಿನ ಹೆಸರನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಅಥವಾ ಸ್ಥಿರ ವಿಳಾಸ ಬಳಸುತ್ತದೆ, ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ನಿಂದ ಬರುವ ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸುವ ಸೇವೆಯನ್ನು ತಲುಪುತ್ತದೆ.

Public client  -> frontend public address:443   (TLS, public name)
Frontend       -> VPN private backend 10.40.0.20:8443  (TLS, private name)

ಇವನ್ನು ಮನಸ್ಸಿನಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ, ಸಂರಚನೆ ಸ್ವಯಂಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಇವನ್ನು ಸೇರಿಸಿದರೆ ಕೊನೆಗೆ ನೀವು ಸಾರ್ವಜನಿಕ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸುರಂಗದಲ್ಲಿ ಭಾಗಿಯಾಗಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೀರಿ, ಈ ವಿನ್ಯಾಸದ ಹೆಚ್ಚಿನ ಗೊಂದಲ ಅಲ್ಲಿಂದಲೇ ಬರುತ್ತದೆ. ಖಾಸಗಿ ಭಾಗ ದುರ್ಬಲವಾಗಿರಬಹುದು. ಸಾರ್ವಜನಿಕ ಭಾಗ ಅಲ್ಲ.

ಇದರಲ್ಲಿ ಏನನ್ನೂ ನಿರ್ಮಿಸುವ ಮೊದಲು, ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕಟಿಸುವುದು ಉದ್ದೇಶಪೂರ್ವಕವೇ ಎಂದು ದೃಢೀಕರಿಸಿ. ಕೆಲಸ ಮಾಡುವ ಪ್ರಾಕ್ಸಿ ಎಂದರೆ ಕೆಲಸ ಮಾಡುವ ಬಹಿರಂಗವೂ ಹೌದು, ಮತ್ತು ದೃಢೀಕರಣ ಮಾದರಿ ನಿರ್ಣಯವಾಗಿರಬೇಕು, ಅಡ್ಡಪರಿಣಾಮವಲ್ಲ.

ಗೇಟ್‌ವೇ ಹೆಸರು ಸುರಂಗದಿಂದ ಪಾರಾಗಬೇಕು

ಹೆಸರು ಪರಿಹಾರದಲ್ಲಿ ಒಂದು ಸೂಕ್ಷ್ಮ ಬಲೆ ಇದೆ. ಖಾಸಗಿ DNS, VPN ಪ್ರೊಫೈಲ್ ತನ್ನ ಗೇಟ್‌ವೇಗಾಗಿ ಬಳಸುವ ಅದೇ ಹೆಸರನ್ನು ಅಳಿಸಿ ಬರೆದರೆ, ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವುದು ಕೊನೆಗೆ ತಾನೇ ರಚಿಸಬೇಕಾದ ಸುರಂಗದ ಮೂಲಕವೇ ಆ ಗೇಟ್‌ವೇ ತಲುಪಲು ಪ್ರಯತ್ನಿಸಬಹುದು. ಸುರಂಗ ಅಸ್ತಿತ್ವಕ್ಕೆ ಬರುವ ಮೊದಲೇ ಕ್ಲೈಂಟ್‌ಗೆ ಆ ಹೆಸರು ಪರಿಹರಿಸಲ್ಪಟ್ಟಿರಬೇಕು. ಒಮ್ಮೆ ಅದು ಸುರಂಗದ ಒಳಗೆ ಪರಿಹರಿಸಲ್ಪಟ್ಟರೆ, ಸಂಪರ್ಕವನ್ನು ಎಂದಿಗೂ ನಿರ್ಮಿಸಲಾಗದು.

ಗೇಟ್‌ವೇ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್‌ಗಾಗಿ ಪ್ರತ್ಯೇಕ ಅನುಮೋದಿತ ಹೆಸರುಗಳನ್ನು ಬಳಸಿ, ಮತ್ತು ಪ್ರತಿ ಹೆಸರು ಅದರ ಗ್ರಾಹಕನಿಗೆ ಬೇಕಾದ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಲ್ಪಡುವಂತೆ ರೆಸಾಲ್ವರ್ ನೀತಿಯನ್ನು ಮಿತಿಗೊಳಿಸಿ. ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ Host ಹೆಡರ್ ಬದಲಾಯಿಸುವುದು ಇಲ್ಲಿ ಏನೂ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಹುಡುಕಾಟವನ್ನು VPN ಕ್ಲೈಂಟ್ ಮಾಡುತ್ತದೆ.

ನಂತರ ವ್ಯಾಪ್ತಿಯ ಬಗ್ಗೆ ಯೋಚಿಸಿ. ಫ್ರಂಟೆಂಡ್‌ಗೆ ಬ್ಯಾಕೆಂಡ್ ವಿಳಾಸದವರೆಗೆ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಉತ್ತರಿಸುವುದನ್ನು ಮುಂದುವರಿಸಬೇಕು. ಆ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಪೂರ್ಣ ಸುರಂಗ ಮೊದಲ ಷರತ್ತನ್ನು ಪೂರೈಸಿ ಎರಡನೆಯದನ್ನು ಮುರಿಯಬಹುದು.

ನೀತಿ ಅನುಮತಿಸುವಲ್ಲಿ, ನಿರ್ದಿಷ್ಟ ಗಮ್ಯಸ್ಥಾನದ ಸುರಂಗ ಹೆಚ್ಚು ಸ್ವಚ್ಛ ವಿನ್ಯಾಸ. ನೀತಿ ಪೂರ್ಣ ಸುರಂಗವನ್ನು ಕಡ್ಡಾಯ ಮಾಡುವಲ್ಲಿ, ಫ್ರಂಟೆಂಡ್ ಪ್ರತ್ಯೇಕ ನೆಟ್‌ವರ್ಕ್ ಸಂದರ್ಭದಲ್ಲಿ ಇರಬೇಕು, ತಿಳಿದ ಸಂದರ್ಶಕರಿಗೆ ತಾತ್ಕಾಲಿಕ ಮಾರ್ಗಗಳಿಂದ ಅಂಟಿಸಬಾರದು.

ಸರ್ವರ್ ಬ್ಲಾಕ್ ಅನ್ನು ಎರಡೂ ಭಾಗಗಳು ಪರಿಶೀಲಿಸುವಂತೆ ಬರೆಯಿರಿ

ಬ್ಯಾಕೆಂಡ್ ಈ ಹೆಸರಿಗೆ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಿ: backend.corp.example ಮತ್ತು ಖಾಸಗಿ ವಿಳಾಸದಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆ. ಹೆಸರನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಿಸುವುದು ಪ್ರಾಕ್ಸಿ ಮಾಡ್ಯೂಲ್‌ನ SNI ಮತ್ತು ಹೆಸರಿನ ಆಯ್ಕೆಗಳ ಉದ್ದೇಶವೇ.

upstream private_app {
    server 10.40.0.20:8443;
}

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

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

    location / {
        proxy_pass https://private_app;
        proxy_ssl_server_name on;
        proxy_ssl_name backend.corp.example;
        proxy_ssl_trusted_certificate /etc/nginx/trust/backend-ca.pem;
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 3;

        proxy_set_header Host app.example.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

ಮೇಲಿನ ಪ್ರತಿ ಮಾರ್ಗ ಮತ್ತು ವಿಳಾಸ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್. ಮುಖ್ಯವಾದವು ಪರಿಶೀಲನೆಯನ್ನು ಆನ್ ಆಗಿ ಇರಿಸುವ ಭಾಗಗಳು: ಪರಿಶೀಲಿಸಬೇಕಾದ ಹೆಸರು, ಅದರ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಬೇಕಾದ ಟ್ರಸ್ಟ್ ಬಂಡಲ್, ಮತ್ತು ಅನುಮೋದಿತ ಸರಪಳಿಗೆ ಹೊಂದುವ ಆಳ.

proxy_set_header Host app.example.com ಉದ್ದೇಶಪೂರ್ವಕ. ಬ್ಯಾಕೆಂಡ್ ಆ ಸಾರ್ವಜನಿಕ ಮೂಲವನ್ನು ಸ್ವೀಕರಿಸುವಂತೆ ಸಂರಚಿಸಬೇಕು, ಮತ್ತು ಈ ಫ್ರಂಟೆಂಡ್‌ನಿಂದ ಮಾತ್ರ ಫಾರ್ವರ್ಡ್ ಆದ ಹೆಡರ್‌ಗಳನ್ನು ನಂಬಬೇಕು. ಅದರ ಮೇಲೆ ಬರೆಯುವುದು X-Forwarded-For ಕ್ಲೈಂಟ್ ವಿಳಾಸದೊಂದಿಗೆ ಒಂದು ಪ್ರಾಕ್ಸಿಗೆ ಸರಿ ಮತ್ತು ಸರಪಳಿಗೆ ತಪ್ಪು, ಆದ್ದರಿಂದ ಬಹು-ಪ್ರಾಕ್ಸಿ ನಿಯೋಜನೆಗೆ ತನ್ನದೇ ವಿಶ್ವಾಸಾರ್ಹ ವಿಳಾಸ ವ್ಯವಸ್ಥೆ ಬೇಕು.

ಸಾರ್ವಜನಿಕ ಮೂಲವನ್ನು ಸಾರ್ವಜನಿಕ ಮೂಲದಂತೆ ವರ್ತಿಸುವಂತೆ ಮಾಡಿ

ಅಪ್ಲಿಕೇಶನ್ ಸಾರ್ವಜನಿಕ ಮೂಲಕ್ಕೆ ಸಂಪೂರ್ಣ URLಗಳು, ಮರುನಿರ್ದೇಶನಗಳು ಮತ್ತು ಕುಕೀಗಳನ್ನು ಹೊರಡಿಸಬೇಕು. ಅದು ಸಂದರ್ಶಕನನ್ನು ಇಲ್ಲಿಗೆ ಮರುನಿರ್ದೇಶಿಸಿದರೆ: backend.corp.example, ಆ ಸಂದರ್ಶಕ ಪರಿಹರಿಸಲಾಗದ ಹೆಸರಿಗೆ ಕಳುಹಿಸಲ್ಪಡುತ್ತಾನೆ.

ಇದನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನ ಬೆಂಬಲಿತ ಬಾಹ್ಯ URL ಸೆಟ್ಟಿಂಗ್ ಮತ್ತು ಪರಿಶೀಲಿತ ಮರುನಿರ್ದೇಶನ ನೀತಿಯಿಂದ ಸರಿಪಡಿಸಿ, ಪ್ರತಿಕ್ರಿಯೆ ಬಾಡಿಗಳಲ್ಲಿ ಹೋಸ್ಟ್ ಹೆಸರುಗಳನ್ನು ಮತ್ತೆ ಬರೆಯುವುದರಿಂದ ಅಲ್ಲ. ಅನಿಯಂತ್ರಿತ ವಿಷಯದಲ್ಲಿ ಸ್ಟ್ರಿಂಗ್ ಬದಲಾವಣೆ ಸಹಿ ಮಾಡಿದ ಪೇಲೋಡ್‌ಗಳನ್ನು ಮುರಿಯುತ್ತದೆ ಮತ್ತು ಹುಡುಕಲು ಕಷ್ಟವಾದ ಬಗ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಕುಕೀಗಳೂ ಅದೇ ಕಾಳಜಿಗೆ ಅರ್ಹ. ಖಾಸಗಿ ಹೆಸರಿಗೆ ಸೀಮಿತವಾದ ಕುಕಿಯನ್ನು ಸಾರ್ವಜನಿಕ ಹೆಸರು ಮಾತ್ರ ತಿಳಿದಿರುವ ಬ್ರೌಸರ್ ಎಂದಿಗೂ ಕಳುಹಿಸುವುದಿಲ್ಲ.

Nginx ನಿಜವಾಗಿಯೂ ಸಾರ್ವಜನಿಕ ಸಾಕೆಟ್‌ನ್ನು ಹೊಂದಬಹುದೇ ಎಂದು ಸಹ ದೃಢೀಕರಿಸಿ. 443 ನಲ್ಲಿ ಇರುವ ಪ್ರಸ್ತುತ ವೆಬ್ ಸೇವೆ ಸರಿಯಬೇಕು ಅಥವಾ ಫ್ರಂಟೆಂಡ್ ಬೇರೆಡೆ ಇರಬೇಕು, ಏಕೆಂದರೆ ಎರಡು ಪ್ರಕ್ರಿಯೆಗಳು ಒಂದೇ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಬೈಂಡ್ ಮಾಡಲಾಗದು.

ಪ್ರತಿ ಭಾಗವನ್ನು ಅದು ನಿಜವಾಗಿ ಚಲಿಸುವಲ್ಲಿಯೇ ಪರಿಶೀಲಿಸಿ

ಯಾವುದೇ ಮರುಲೋಡ್‌ಗಿಂತ ಮೊದಲು ಸಂರಚನೆಯನ್ನು ಸ್ಥಾಪಿತ ಪಾರ್ಸರ್‌ನಿಂದ ಮಾನ್ಯಗೊಳಿಸಿ, ಟೈಪಿಂಗ್ ತಪ್ಪು ಈಗ ಸೇವೆ ಮಾಡುತ್ತಿರುವ ಶ್ರೋತೃವನ್ನು ಉರುಳಿಸದಂತೆ.

ನಂತರ ಬ್ಯಾಕೆಂಡ್ ಭಾಗವನ್ನು ಫ್ರಂಟೆಂಡ್ ಹೋಸ್ಟ್‌ನಿಂದಲೇ, Nginx ಬಳಸುವ ಅದೇ ನೆಟ್‌ವರ್ಕ್ ಸಂದರ್ಭದಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ. ಸುರಂಗದ ಮೂಲಕ ping ತಲುಪುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, TLS, ಅಧಿಕಾರ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಬಗ್ಗೆ ಏನೂ ಅಲ್ಲ.

ಕೊನೆಗೆ ನಿಜವಾದ ಹೋಸ್ಟ್ ಹೆಸರಿಗೆ ಸಾಮಾನ್ಯ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಯೊಂದಿಗೆ ಹೊಸ ಸಾರ್ವಜನಿಕ ವಿನಂತಿ ಕಳುಹಿಸಿ, ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಬಾಡಿ ಮಾತ್ರವಲ್ಲ ಪ್ರತಿಕ್ರಿಯೆ ಮಾರ್ಗವನ್ನು ಗಮನಿಸಿ.

ಎರಡೂ ವೀಕ್ಷಣೆಗಳನ್ನು ನಿಯೋಜಿತ ಸಂರಚನೆಯೊಂದಿಗೆ ಇರಿಸಿ ಮತ್ತು ಸುರಂಗ ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ದಾಖಲಿಸಿ. ಫ್ರಂಟೆಂಡ್ ನಿಯಂತ್ರಿತ upstream ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು, ಯಾರೂ ದಾಖಲಿಸದ ಇನ್ನೊಂದು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಸದ್ದಿಲ್ಲದೆ ಬೀಳಬಾರದು. ಸ್ಪಷ್ಟ ಲಾಗ್ ಸಾಲಿನೊಂದಿಗೆ 502 ಉತ್ತಮ ಫಲಿತಾಂಶ. ಅನುದ್ದಿಷ್ಟ ಮೂಲದಿಂದ ಕ್ಯಾಶ್ ಆದ ಪುಟ ಹಾಗಲ್ಲ.