NGINX ಸ್ಟ್ರೀಮ್ ರಿಲೇ ಮೂಲಕ SSH — ಮುರಿಯದೆ

ರಿಲೇ ಮೂಲಕ ಸಾರ್ವಜನಿಕ SSH ಎರಡು ಸಂಬಂಧವಿಲ್ಲದ ಗಡಿಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಒಂದನ್ನು ಸರಿಪಡಿಸಿದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಇನ್ನೊಂದು ಬಯಲಾಗುತ್ತದೆ. ಒಂದೋ ಅಂಚು ಸ್ಟ್ರೀಮ್ ಸಾಗಿಸುವ ಬದಲು HTTP ಪ್ರತಿಕ್ರಿಯೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಅಥವಾ ರಿಲೇ ಬ್ಯಾಕೆಂಡ್ ಒಪ್ಪದ ಹೆಡರ್ ಅನ್ನು ಮುಂದೆ ಸೇರಿಸುತ್ತದೆ. ನೀವು ಯಾವುದನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಮೂರು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ: ಸಾರ್ವಜನಿಕ ದಾಖಲೆ ನಿಜವಾಗಿ ಯಾವುದನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಸ್ಟ್ರೀಮ್ ಬ್ಲಾಕ್ ಮೇಲಕ್ಕೆ ಏನು ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು SSH ಕ್ಲೈಂಟ್ ಯಾವ ಹೆಸರನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅವುಗಳನ್ನು ಆ ಕ್ರಮದಲ್ಲಿ ನಿಭಾಯಿಸಿ.

ಎರಡು ಗಡಿಗಳು, ಎರಡು ಲಕ್ಷಣಗಳು

ಅಂಚಿನ ವೈಫಲ್ಯವು SSH ಬ್ಯಾನರ್ ಇರಬೇಕಾದಲ್ಲಿ HTTP ಸ್ಥಿತಿ ಪುಟ ಬರುತ್ತಿರುವಂತೆ ಕಾಣುತ್ತದೆ. ಸಂಪರ್ಕ TCP ಮಟ್ಟದಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಮೊದಲ ಬೈಟ್ಗಳು ವೆಬ್ ಸರ್ವರ್ಗೆ ಸೇರಿದ ಪಠ್ಯ. ಇದು ಪ್ರೋಟೋಕಾಲ್ ಹೊಂದಾಣಿಕೆಯಲ್ಲದಿರುವಿಕೆ, ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ ಅಲ್ಲ. ಅಂಚು ಆ ಹೆಸರಿಗೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬೇರೆ ಯಾವುದನ್ನೋ ನೀಡುತ್ತಿದೆ ಎಂದೂ ಇದು ಹೇಳುತ್ತದೆ.

ಮೇಲ್ಮುಖದ ವೈಫಲ್ಯ ಬೇರೆ ರೀತಿ ಕಾಣುತ್ತದೆ. ಸಂಪರ್ಕ sshd ತಲುಪುತ್ತದೆ, sshd ತಾನು ನಿರೀಕ್ಷಿಸುವ ಗುರುತಿಸುವಿಕೆ ವಿನಿಮಯವಲ್ಲದ ಬೈಟ್ಗಳನ್ನು ಓದುತ್ತದೆ, ಮತ್ತು ಸೆಷನ್ ಎಂದಿಗೂ ಕೀಲಿಯನ್ನು ನೀಡದೆ ಸಾಯುತ್ತದೆ ಅಥವಾ ನೇತಾಡುತ್ತದೆ.

ಈ ಎರಡನ್ನು ಗೊಂದಲ ಮಾಡಿಕೊಳ್ಳುವುದು ಸುಲಭ, ಏಕೆಂದರೆ ಎರಡೂ ಸಂಪರ್ಕಿಸಿ ನಂತರ ವಿಫಲವಾಗುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ. ನೀವು ಪಡೆಯುವ ಮೊದಲ ಪ್ರೋಟೋಕಾಲ್ ಪ್ರತಿಕ್ರಿಯೆಯೇ ಅವನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಟಿಕೆಟ್ನಲ್ಲಿರಬೇಕು.

PROXY ಹೆಡರ್ ಒಂದು ಸಂದೇಶ, ಸ್ವಿಚ್ ಅಲ್ಲ

ಸ್ಟ್ರೀಮ್ ಮಾಡ್ಯೂಲ್ನಲ್ಲಿ, proxy_protocol on NGINX ಗೆ ಪೇಲೋಡ್ಗೆ ಮೊದಲು ಮೇಲ್ಮುಖಕ್ಕೆ PROXY ಪ್ರೋಟೋಕಾಲ್ ಹೆಡರ್ ಬರೆಯಲು ಸೂಚಿಸುತ್ತದೆ. ಇದು TCP ಪ್ರಾಕ್ಸಿಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು SSH ಎನ್ಕ್ರಿಪ್ಷನ್ಗೆ ಇದಕ್ಕೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ. ಇದು ಸ್ವೀಕರಿಸುವವರಿಗೆ ಉದ್ದೇಶಿಸಿದ ಟಿಪ್ಪಣಿ. ಸ್ವೀಕರಿಸುವವರು ಅದನ್ನು ಓದಲಾಗದಿದ್ದರೆ, ಅದು ಸ್ಟ್ರೀಮ್ನ ಆರಂಭದಲ್ಲಿ ಕಸ ಆಗುತ್ತದೆ.

ಸ್ವೀಕರಿಸುವ ಸೇವೆ ಆ ಹೆಡರ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೇವಿಸಬೇಕು. ಸಾಮಾನ್ಯ sshd ಸಂಪರ್ಕದ ಮೊದಲ ಬೈಟ್ಗಳಾಗಿ SSH ಗುರುತಿಸುವಿಕೆ ವಿನಿಮಯವನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅನಿರೀಕ್ಷಿತ ಪೂರ್ವಭಾವಿ ಹಸ್ತಲಾಘವವನ್ನು ಹಾಳಾದ ಸರ್ವರ್ನಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ಮುರಿಯುತ್ತದೆ.

stream {
    server {
        listen 2222;
        proxy_pass 10.77.0.20:22;
    }
}

ಆ ತುಣುಕು VPN ಮೂಲಕ ತಲುಪಬಹುದಾದ ಬ್ಯಾಕೆಂಡ್ಗೆ ಪೂರ್ಣ ಕೆಲಸ ಮಾಡುವ ರಿಲೇ ಆಗಿದೆ. ಯಾವುದೇ PROXY ನಿರ್ದೇಶನ ಕಾಣಿಸುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಸ್ವೀಕರಿಸುವವರು ಆ ಪ್ರೋಟೋಕಾಲ್ ಮಾತನಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಆ ಅನುಪಸ್ಥಿತಿ ಬಿಟ್ಟುಬಿಡುವಿಕೆ ಅಲ್ಲ, ಒಂದು ನಿರ್ಣಯ.

ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನೂ ಪ್ರತ್ಯೇಕಿಸಿ. listen ಸಾಲಿನಲ್ಲಿ proxy_protocol ಹೊಂದಿಸುವುದು ಎಂದರೆ NGINX ತನ್ನದೇ ಕ್ಲೈಂಟ್ ಮೊದಲು ಹೆಡರ್ ಕಳುಹಿಸುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುತ್ತದೆ; ಸಾಮಾನ್ಯ SSH ಕ್ಲೈಂಟ್ಗೆ ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಸಮಸ್ಯೆಯ ನಿಖರ ವಿರುದ್ಧವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಸಾರ್ವಜನಿಕ ಹೋಸ್ಟ್ನಾಮ್ ನಿಜವಾಗಿ ಯಾವುದನ್ನು ತಲುಪುತ್ತದೆ

SSH ಸೆಷನ್ನಲ್ಲಿ HTTP 400 ಪುಟವು ಅಂಚಿನ ಬಗ್ಗೆ ಸಾಕ್ಷಿ. ಮಾರ್ಗದಲ್ಲಿ ಯಾವುದೋ HTTP ಮಾತನಾಡುತ್ತದೆ, ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ನಲ್ಲಿ ಕೀಲಿ ಅಥವಾ ಖಾತೆಯ ಮೇಲಿನ ಯಾವುದೇ ಕೆಲಸ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಅಂಚು ನಿರ್ಣಯವಾಗುವವರೆಗೆ ಬ್ಯಾಕೆಂಡ್ ಬದಲಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ.

Cloudflare ನ ಸಾಮಾನ್ಯ ಪ್ರಾಕ್ಸಿ ಮಾಡಿದ ದಾಖಲೆ ತನ್ನ ಬೆಂಬಲಿತ HTTP ಮತ್ತು HTTPS ಸಂಚಾರವನ್ನು ನಿರ್ದಿಷ್ಟ ಪೋರ್ಟ್ಗಳಲ್ಲಿ ಸಾಗಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ನಾಮ್ಗೆ ಪ್ರಾಕ್ಸಿ ಆನ್ ಮಾಡುವುದು ಸಾಮಾನ್ಯ TCP ರಿಲೇಯನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ, ಮತ್ತು SSH ಅನ್ನು ಪೋರ್ಟ್ 443 ಗೆ ಸರಿಸುವುದು ಅದನ್ನು HTTPS ಮಾಡುವುದಿಲ್ಲ.

ಎರಡು ಕಾರ್ಯಸಾಧ್ಯ ದಿಕ್ಕುಗಳಿವೆ. ಕೇವಲ DNS ದಾಖಲೆ ನಿಮ್ಮ ಸ್ವಂತ TCP ರಿಲೇಗೆ ಸೂಚಿಸಬಹುದು, ಇದು ಒಡ್ಡುವಿಕೆಯ ನಿರ್ಣಯವನ್ನು ನಿಮ್ಮ ಕೈಯಲ್ಲಿ ಇಡುತ್ತದೆ. ಪರ್ಯಾಯವಾಗಿ, SSH ಸಾಗಣೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ದಾಖಲಿಸುವ ಉತ್ಪನ್ನವನ್ನು ಬಳಸಿ, ಅದರ ಸ್ವಂತ ಮೂಲ, ಕ್ಲೈಂಟ್ ಮತ್ತು ಪ್ರವೇಶ ಸಂರಚನೆಯೊಂದಿಗೆ.

ನೀವು ಯಾವುದನ್ನು ಆರಿಸಿದರೂ, ರಿಲೇಗೆ ಇನ್ನೂ ಬ್ಯಾಕೆಂಡ್ಗೆ VPN ಮಾರ್ಗ, ಅನುಮತಿಸಿದ ಸಂಪರ್ಕ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು. ಮಾರ್ಗವು ಐಚ್ಛಿಕವಲ್ಲ ಏಕೆಂದರೆ ಸಾರ್ವಜನಿಕ ಬದಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಅಲಿಯಾಸ್ ಮೂಲಕ SSH ಗುರುತನ್ನು ಸ್ಥಿರವಾಗಿರಿಸಿ

ಬಳಕೆದಾರರು ಸಾಮಾನ್ಯವಾಗಿ ತಮ್ಮ ಇರುವ ಹೋಸ್ಟ್ನಾಮ್ ಟೈಪ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಲು ಬಯಸುತ್ತಾರೆ. SSH ಸಂರಚನೆಯ ಅಲಿಯಾಸ್ ರಿಲೇ ಬಗ್ಗೆ ಏನನ್ನೂ ಬದಲಿಸದೆ ಅದನ್ನು ಮಾಡಬಹುದು, ಮತ್ತು ಬದಲಾವಣೆಯನ್ನು ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಅದರ ಸ್ಥಾನದಲ್ಲಿ ಇಡುತ್ತದೆ.

Host git.example.com
    HostName ssh-entry.example.net
    Port 2222
    User git
    HostKeyAlias git.example.com

HostKeyAlias ಇಲ್ಲದೆ, OpenSSH ತಾನು ಸಂಪರ್ಕಿಸುವ ಹೆಸರಿನ ಅಡಿಯಲ್ಲಿ ಹೋಸ್ಟ್ ಕೀಲಿಯನ್ನು ಹುಡುಕುತ್ತದೆ, ಆದ್ದರಿಂದ ನಮೂದು ಜಾರುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಬಳಕೆದಾರರು ಮೊದಲ ಬಳಕೆಯಲ್ಲಿ ಬದಲಾದ ಕೀಲಿಯ ಎಚ್ಚರಿಕೆ ನೋಡುತ್ತಾರೆ. ಅಲಿಯಾಸ್ ಹೊಂದಿಸುವುದು known-hosts ನಮೂದುಗಳನ್ನು ಸ್ಥಿರವಾಗಿರಿಸುತ್ತದೆ, ಸಂಪರ್ಕ ಇನ್ನೂ ರಿಲೇಗೆ ಹೋಗುತ್ತದೆ.

ಈ ಅಲಿಯಾಸ್ SSH ಆಧಾರಿತ ರಿಮೋಟ್ಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ. HTTPS Git URL ಅನ್ನು ಅದು ಪರಿಗಣಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸಾಮಾನ್ಯ ರಿಮೋಟ್ URL ನೀವು ನಿಜವಾಗಿ ಸಿದ್ಧಪಡಿಸಿದ ಸಾಗಣೆಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು.

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

ಪ್ರತಿ ಹಾಪ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ

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

ಪ್ರತಿ ಫಲಿತಾಂಶದೊಂದಿಗೆ ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸ, ಪೋರ್ಟ್ ಮತ್ತು ಮೊದಲ ಪ್ರೋಟೋಕಾಲ್ ಬೈಟ್ಗಳನ್ನು ಇರಿಸಿ. ಆ ತ್ರಿಕವು ಅಂಚಿನ ದೋಷವನ್ನು VPN ರೂಟಿಂಗ್ ಸಮಸ್ಯೆ ಮತ್ತು SSH ದೃಢೀಕರಣ ವೈಫಲ್ಯದಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ದುರಸ್ತಿ ಮತ್ತು ಊಹೆಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸ.

ಕೊನೆಯದಾಗಿ, ಉದ್ದೇಶಿಸಿದ ಒಡ್ಡುವಿಕೆಯನ್ನು ದಾಖಲಿಸಿ. ಖಾಸಗಿ ಬ್ಯಾಕೆಂಡ್ಗೆ SSH ಸಾಗಿಸುವ TCP ರಿಲೇ ಸಾರ್ವಜನಿಕ ಪರಿಧಿಯಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕ ತೆರವು, ಮತ್ತು ಅದು ಯಾವುದೇ ಇತರ ಒಳಬರುವ ಸೇವೆಯಂತೆಯೇ ಅದೇ ಪರಿಶೀಲನೆಗೆ ಅರ್ಹವಾಗಿದೆ.