NGINX stream ಸಂದರ್ಭದಲ್ಲಿ TLS passthrough ಸಂಪರ್ಕವನ್ನು ಅನುಮತಿಸಿ
NGINX TLS ಅನ್ನು ಮುಗಿಸದೆಯೇ TCP TLS ರಿಲೇಯನ್ನು ನಿರಾಕರಿಸಬಹುದು. ಅನುಮತಿ ನಿಯಮವನ್ನು HTTP location ನಲ್ಲಿ ಅಲ್ಲ, stream ನಲ್ಲಿ ಇರಿಸಿ, ಮತ್ತು ಯಾವ peer ವಿಳಾಸ ಬರುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.
ಪ್ರಮಾಣಪತ್ರವನ್ನು ಎಂದಿಗೂ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳದೆ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಬೈಟ್ಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವುದು TLS passthrough ರಿಲೇ ಮಾಡುವ ಕೆಲಸ, ಮತ್ತು ಈ ವ್ಯವಸ್ಥೆ ಅನುಕೂಲಕರವೂ ಮತ್ತು ಸ್ವಲ್ಪ ಗೊಂದಲಮಯವೂ ಆಗಿದೆ. ಏನೂ ಡೀಕ್ರಿಪ್ಟ್ ಆಗದ ಕಾರಣ, ಫಿಲ್ಟರ್ ಮಾಡಲು HTTP ಆಕಾರದ ಯಾವುದೂ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ location ಬ್ಲಾಕ್ ಮತ್ತು ಅದರ ಪ್ರವೇಶ ನಿಯಮಗಳು ಇಲ್ಲಿ ಯಾವುದೇ ಉಪಯೋಗವಿಲ್ಲ. NGINX ಬಳಿ ಇರುವ ನಿರ್ಧಾರ ಸಂಪರ್ಕದ ಬಗ್ಗೆ: ಯಾವ ನೆಟ್ವರ್ಕ್ peer ಬಾಗಿಲು ತಟ್ಟಿತು, ಮತ್ತು ಆ peer ಅನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಬೇಕೇ.
ನಿರ್ಧಾರ stream ನಲ್ಲಿದೆ, HTTP ನಲ್ಲಿ ಅಲ್ಲ
stream ಸಂದರ್ಭದಲ್ಲಿ NGINX TCP ಸೆಷನ್ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅದು ಸಂಪರ್ಕದ peer ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಬೈಟ್ backend ತಲುಪುವ ಮೊದಲು ಅದರ ಮೇಲೆ ಕ್ರಮಬದ್ಧ allow ಮತ್ತು deny ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸಬಹುದು. ಇದು ಸಂಪೂರ್ಣ ಪ್ರವೇಶ ನಿರ್ಧಾರ ಮತ್ತು ಇದಕ್ಕೆ ಖಾಸಗಿ ಕೀ, ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ HTTP ಪಾರ್ಸಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲ.
| Mechanism | What it decides | Where it lives |
|---|---|---|
| stream allow/deny | Whether this TCP peer is relayed | stream server block |
| ssl_preread map | Which backend a named connection goes to | stream, with the preread module |
| HTTP location rule | Whether an HTTP request is served | http server block |
ಆ ಮೂರು ಸಾಲುಗಳು ಎಂದಿಗೂ ಪರಸ್ಪರ ಬದಲಾಗುವುದಿಲ್ಲ. 443 ಪೋರ್ಟ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುವ ಯಾವುದೇ ಫೈಲ್ಗೆ HTTP ಪ್ರವೇಶ ಸೂಚನೆಯನ್ನು ನಕಲಿಸುವುದರಿಂದ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ stream ಸರ್ವರ್ ಎಂದಿಗೂ http ಸಂದರ್ಭವನ್ನು ಓದುವುದಿಲ್ಲ.
ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಮೊದಲು ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸಿ
stream ಮತ್ತು stream-access ಮಾಡ್ಯೂಲ್ಗಳು ಲಭ್ಯವಿರುವ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸ್ಥಾಪನೆ ಇದೆ ಎಂದು ಊಹಿಸಿ, VPN ಕ್ಲೈಂಟ್ಗಳು ಮೂಲ ವಿಳಾಸಗಳನ್ನು 10.90.0.0/24 ನಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತಾರೆ, ಮತ್ತು 192.168.50.20:443 ನಲ್ಲಿ backend ಈಗಾಗಲೇ ಉದ್ದೇಶಿತ HTTPS ಗುರುತನ್ನು ನೀಡುತ್ತಿದೆ.
stream {
server {
listen 443;
allow 10.90.0.0/24;
deny all;
proxy_pass 192.168.50.20:443;
}
}ಇದನ್ನು ಹೊಸ listener ನ ತುಣುಕು ಎಂದು ಓದಿ, ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಸಂರಚನೆಯ ನೇರ ಬದಲಿಯಾಗಿ ಅಲ್ಲ. ಮೊದಲು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ listener ಮತ್ತು include ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಈಗಾಗಲೇ ಆಕ್ರಮಿಸಲಾದ ಪೋರ್ಟ್ನಲ್ಲಿ ಎರಡನೇ listener ವಿನಂತಿಯ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ, reload ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.
ಏನು ಇಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ: listen ... ssl ಇಲ್ಲ, ಪ್ರಮಾಣಪತ್ರ ಸೂಚನೆ ಇಲ್ಲ. NGINX ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಹರಿವನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು backend TLS ಅನ್ನು ಮುಗಿಸಿ ಕ್ಲೈಂಟ್ ಪರಿಶೀಲಿಸುವ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ. allowlist ನಲ್ಲಿ ವಿಫಲವಾದ ಕ್ಲೈಂಟ್ನ TCP ಸೆಷನ್ ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತದೆ, HTTP 403 ಪುಟವಲ್ಲ, ಮತ್ತು ಸ್ಥಿತಿ ಕೋಡ್ ನಿರೀಕ್ಷಿಸುವ ಯಾವುದೇ ಸಾಧನವು ನಿರುಪಯುಕ್ತವಾದದ್ದನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ.
allowlist ಏನನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಏನನ್ನು ಇಲ್ಲ
ರಿಲೇ ಈಗಾಗಲೇ ಸರ್ವರ್ ಹೆಸರಿನಿಂದ backend ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಿದ್ದರೆ, ಮಾಡ್ಯೂಲ್ ಲಭ್ಯವಿದ್ದರೆ ssl_preread ಮತ್ತು map ಆ ಕೆಲಸವನ್ನು ಮುಂದುವರಿಸಬಹುದು. ಹೆಸರನ್ನು ಇನ್ನೂ ಕ್ಲೈಂಟ್ ಒದಗಿಸುತ್ತದೆ, ಮತ್ತು ಹೆಸರನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುವುದು ಕ್ಲೈಂಟ್ VPN ಗೆ ಸೇರಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಉದಾಹರಣೆ ನಿಯಮವು ಇಡೀ stream listener ಅನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಇದು ಸಾರ್ವಜನಿಕ ಮತ್ತು VPN-ಮಾತ್ರ ಸೈಟ್ಗಳ ಮಿಶ್ರಣವನ್ನು ನೀಡುವ ಒಂದೇ ಪ್ರವೇಶ ಬಿಂದುವಿಗೆ ಸೂಕ್ತವಲ್ಲ, ಅಲ್ಲಿ ಪ್ರತಿ ಹೆಸರಿಗೂ ವಿನಾಯಿತಿ ಬೇಕಾಗುತ್ತದೆ; ಯಾರೂ ಓದಲಾಗದ ಹೆಸರಾಧಾರಿತ ನೀತಿಗಿಂತ ಪ್ರತ್ಯೇಕ listener ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿರುತ್ತವೆ.
ಇನ್ನೂ ಎರಡು ಕೊರತೆಗಳನ್ನು ಹೆಸರಿಸುವುದು ಯೋಗ್ಯ. prefix ಹೊಂದಾಣಿಕೆಯು ಪ್ಯಾಕೆಟ್ ಯಾವ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಬಂತು ಎಂದು ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಬೇರೆಡೆಯ HTTP ನಿಯಮವು ಈ listener ಅನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗದು. ಎರಡೂ ಒಂದು allow ಸಾಲನ್ನು ಇಡೀ ಗಡಿ ಎಂದು ಪರಿಗಣಿಸುವ ಬದಲು ಹೋಸ್ಟ್ ಮಟ್ಟದ ingress ನೀತಿಯನ್ನು ಚಿತ್ರದಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳುವ ಕಾರಣಗಳು. ಗಡಿಯನ್ನು ಒಪ್ಪಬೇಕಾದ ಎರಡು ನಿಯಂತ್ರಣಗಳಾಗಿ ಬರೆಯಿರಿ, ಇದರಿಂದ ಯಾವುದಾದರೂ ಬದಲಾವಣೆ ಪರಿಶೀಲನೆಗೆ ಒಳಗಾಗುತ್ತದೆ.
NGINX ನಿಜವಾಗಿ ಯಾರ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ?
ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್, ಇನ್ನೊಂದು proxy ಅಥವಾ source NAT NGINX ಮುಂದೆ ಮಧ್ಯವರ್ತಿಯನ್ನು ಇರಿಸಬಹುದು, ಆದ್ದರಿಂದ ಕಾಣುವ peer VPN ಕ್ಲೈಂಟ್ನ ಒಳಗಿನ ವಿಳಾಸವಲ್ಲ. prefix ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ನಿಜವಾದ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ತಪ್ಪು ವಿಳಾಸಕ್ಕೆ ಬರೆದ allowlist ಅನುವಾದಕರ ಹಿಂದೆ ಎಲ್ಲರನ್ನೂ ಒಪ್ಪುತ್ತದೆ ಅಥವಾ ಯಾರನ್ನೂ ಒಪ್ಪುವುದಿಲ್ಲ.
PROXY ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ನಿಜವಾದ IP ನಿರ್ವಹಣೆ ಕಾನೂನುಬದ್ಧ ಉತ್ತರಗಳು, ಮತ್ತು ಅವುಗಳನ್ನು ಹೊಂದಿಕೊಳ್ಳುವ, ಸ್ಪಷ್ಟವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹ ಕಳುಹಿಸುವವರಿಗೆ ಮಾತ್ರ ಸಂರಚಿಸಬೇಕು. ಎರಡೂ ಕಾರ್ಯವಿಧಾನಗಳು ಕಳುಹಿಸುವವರು ಹೇಳುವುದನ್ನು ನಂಬುತ್ತವೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಕಳುಹಿಸುವವರ ಪಟ್ಟಿ ಚಿಕ್ಕದಾಗಿರಬೇಕು. ಯಾವುದೇ ಇಂಟರ್ನೆಟ್ ಕ್ಲೈಂಟ್ನ ಗುರುತು ಹೆಡರ್ ಅನ್ನು ನಂಬುವುದು ಮೂಲ ಮಾಹಿತಿಯನ್ನು ಮತ್ತೆ ವಿಶ್ವಾಸಾರ್ಹಗೊಳಿಸುವುದಿಲ್ಲ; ಅದು ಸರಿಯಾದ ನಿರಾಕರಣೆಯನ್ನು ನಕಲಿ ಸ್ವೀಕಾರವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
reload ಮೊದಲು ಎರಡೂ ಫಲಿತಾಂಶಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
ಸಂರಚನೆಯನ್ನು ಮೌಲ್ಯೀಕರಿಸಿ, reload ಮಾಡಿ, ನಂತರ ಎರಡು ಬಾರಿ ಪರೀಕ್ಷಿಸಿ: ಕೆಲಸ ಮಾಡಬೇಕಾದ ಹೊಸ ಅನುಮತಿಸಿದ ಸೆಷನ್, ಮತ್ತು ಕೆಲಸ ಮಾಡಬಾರದ ತಿರಸ್ಕೃತ ಸೆಷನ್. ಅನುಮತಿಸಿದ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಸಾಮಾನ್ಯ backend ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಯನ್ನು ಇರಿಸಿ, ಏಕೆಂದರೆ ಸಂಪರ್ಕಿಸುವ ಆದರೆ backend ಅನ್ನು ಪರಿಶೀಲಿಸಲಾಗದ ರಿಲೇ ಒಂದು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿ ಇನ್ನೊಂದನ್ನು ಸೃಷ್ಟಿಸಿದೆ.
nginx -t
ss -tnp | grep ':443'backend ಮಾರ್ಗ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಯೂ ಪರಿಶೀಲಿಸಿ. allowlist ದಾಟುವುದು NGINX ಸೆಷನ್ ಸ್ವೀಕರಿಸಿದೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಅದು ತಲುಪಲಾಗದ backend ಪ್ರತಿಕ್ರಿಯಿಸುವಂತೆ ಮಾಡಲಾಗದು, ಮತ್ತು ನೀವು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಕಾಣೆಯಾಗಿದ್ದ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಲಾಗದು.