ಒಂದು ಕ್ಲೌಡ್ ಸೇವೆಗಾಗಿ ಸ್ಥಳೀಯ TLS, SSH ಫಾರ್ವರ್ಡ್ ಅಥವಾ VPN

ಎರಡು ಕ್ಲೌಡ್ ಯಂತ್ರಗಳ ನಡುವೆ ಏನನ್ನಾದರೂ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಬೇಕೇ ಎಂಬುದು ಪ್ರಶ್ನೆ ಅಪರೂಪ; ನೀವು ಯಾವ ಇಂಟರ್ಫೇಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಯಾರು ಯಾರ ಗುರುತನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾರೆ ಎಂಬುದು ಪ್ರಶ್ನೆ. ನಾನು ಈ ಸಂಭಾಷಣೆಗಳನ್ನು ನೆಟ್‌ವರ್ಕ್ ರೇಖಾಚಿತ್ರದಿಂದ ಅಲ್ಲ, ಸೇವೆಯಿಂದ ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಸೇವೆಗೆ ಈಗಾಗಲೇ ಏನು ಬೇಕು ಎಂದು ತಿಳಿದಿದೆ. ಮೂರು ಗಡಿಗಳು ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳನ್ನು ಆವರಿಸುತ್ತವೆ: ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ TLS, SSH ಮೂಲಕ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಒಂದು TCP ಪೋರ್ಟ್, ಮತ್ತು ಪ್ರತಿ ಭಾಗವಹಿಸುವವರಿಗೆ ವಿಳಾಸ ನೀಡುವ ರೂಟೆಡ್ ಓವರ್‌ಲೇ. ಅವುಗಳನ್ನು ಶಕ್ತಿಯ ಪ್ರಕಾರವಲ್ಲ, ಸಮಸ್ಯೆಯ ಎಷ್ಟು ಭಾಗವನ್ನು ಆವರಿಸುತ್ತವೆ ಎಂಬ ಪ್ರಕಾರ ಜೋಡಿಸಲಾಗುತ್ತದೆ.

ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಅಲ್ಲ, ಸೇವೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಪ್ರಕ್ರಿಯೆಯಿಂದ ಹೊರಕ್ಕೆ ಹೋಗಿ. ಅದು ಯಾವ ಪ್ರೋಟೋಕಾಲ್ ಮಾತನಾಡುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಯಾವ ಹೆಸರನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಮತ್ತು ಯಾರಿಗೆ ಸಂಪರ್ಕ ತೆರೆಯಲು ಅನುಮತಿ ಇದೆ? ಆ ಮೂರು ಉತ್ತರಗಳು ಯಾವುದೇ ಹೋಲಿಕೆ ಕೋಷ್ಟಕಕ್ಕಿಂತ ವೇಗವಾಗಿ ಆಯ್ಕೆಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತವೆ, ಮತ್ತು ಸೇವೆಯ ಸ್ವಂತ ಸಂರಚನೆ ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವು ನಿಮಿಷಗಳಲ್ಲಿ ಅವುಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ.

8443 ಪೋರ್ಟ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ HTTPS ನೀಡುತ್ತಿರುವ ಸಣ್ಣ ಆಂತರಿಕ API ತೆಗೆದುಕೊಳ್ಳಿ, api.internal.example ಗಾಗಿ ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗೆ. ಹೋಸ್ಟ್‌ನಲ್ಲಿ ss -ltnp ಅದು ಯಾವುದಕ್ಕೆ ಬಂಧಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example ಪ್ರಮಾಣಪತ್ರವು ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಬಳಸುವ ಹೆಸರಿಗೆ ಮಾನ್ಯವೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಎರಡೂ ಆರೋಗ್ಯಕರವಾಗಿದ್ದರೆ, ಸೇವೆ ತನ್ನ ಸ್ವಂತ ಹರಿವನ್ನು ರಕ್ಷಿಸಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಕೇವಲ ತಲುಪುವಿಕೆ ಉಳಿಯುತ್ತದೆ. ಇದು ನೆಟ್‌ವರ್ಕ್ ನಿರ್ಮಿಸುವುದಕ್ಕಿಂತ ಬಹಳ ಚಿಕ್ಕ ಸಮಸ್ಯೆ.

ಹಂತ 1: ಸೇವೆ ತನ್ನನ್ನು ರಕ್ಷಿಸಿಕೊಳ್ಳುತ್ತದೆಯೇ?

ಇದು ಸರಿಹೊಂದಿದಾಗ ಆಯ್ಕೆ ಮಾಡುವ ಆಯ್ಕೆ, ಮತ್ತು ತಂಡಗಳು ಊಹಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಸರಿಹೊಂದುತ್ತದೆ. ಸೇವೆಯ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಇಡೀ ಮಾರ್ಗವನ್ನು ಆವರಿಸುತ್ತದೆ, ನಡುವಿನ ಪ್ರತಿ ಹಾಪ್ ಸೇರಿದಂತೆ, ಮಧ್ಯದ ಸುತ್ತಲಿನ ಯಾವುದೇ ಸುರಂಗ ಅದನ್ನು ಸುಧಾರಿಸುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್‌ನ ಡೀಫಾಲ್ಟ್ ಸ್ಟೋರ್‌ನಲ್ಲಿ ಆಕಸ್ಮಿಕವಾಗಿ ಇರುವುದನ್ನು ಅವಲಂಬಿಸುವ ಬದಲು ನಿರೀಕ್ಷಿತ ಹೆಸರು ಮತ್ತು ನಂಬಿಕೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸಿ.

ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಮತ್ತು ತಲುಪುವಿಕೆ ಪ್ರತ್ಯೇಕ ನಿಯಂತ್ರಣಗಳಾಗಿ ಉಳಿಯುತ್ತವೆ, ಮತ್ತು ಅವುಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವುದೇ ಈ ಆಯ್ಕೆ ತಪ್ಪಾಗುವ ಸ್ಥಳ. ಅನಿರ್ಬಂಧಿತ ಸಾರ್ವಜನಿಕ ಶ್ರೋತೃದಲ್ಲಿರುವ TLS ಸೇವೆ ಇನ್ನೂ ಯಾರಿಂದಲಾದರೂ ಸಂಪರ್ಕ ಪ್ರಯತ್ನಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪೇಲೋಡ್ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದೆ ಎಂಬ ಅಂಶದಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಶ್ರೋತೃ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ನಿಯಮಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬೇಕು. ನಂತರ ಅವಲಂಬನೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ TLS ಮೇಲಿನ API ಡಿಸ್ಕವರಿ ಎಂಡ್‌ಪಾಯಿಂಟ್, ನಿರ್ವಾಹಕ ಪೋರ್ಟ್ ಅಥವಾ ಪಕ್ಕದ ಬೃಹತ್ ವರ್ಗಾವಣೆ ಚಾನಲ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಉತ್ತರ ಬೇಕು, ಮತ್ತು ಒಂದು ಅಸುರಕ್ಷಿತ ಸಹೋದರ ಇಡೀ ಗಡಿಯನ್ನು ಕಾಲ್ಪನಿಕವಾಗಿಸಲು ಸಾಕು.

ಹಂತ 2: ಒಂದು TCP ಪೋರ್ಟ್‌ನಿಂದಲೇ ಇಡೀ ಅಗತ್ಯವೇ?

ಅಗತ್ಯವು ನಿಜವಾಗಿಯೂ ಒಂದು TCP ಪೋರ್ಟ್ ಆದಾಗ, ಫಾರ್ವರ್ಡ್ ಕೆಲಸ ಮಾಡುವ ಚಿಕ್ಕ ವಿಷಯ. SSH ಸ್ಥಳೀಯ ಫಾರ್ವರ್ಡ್ ಆ ಪೋರ್ಟ್ ಅನ್ನು ಈಗಾಗಲೇ ಇರುವ ದೃಢೀಕೃತ ಸಂಪರ್ಕದ ಮೂಲಕ ಸಾಗಿಸುತ್ತದೆ.

ಆಕಾರ ssh -N -L 8443:127.0.0.1:8443 [email protected], ಮತ್ತು ಮುಖ್ಯ ವಿವರ ಗುರಿ ವಿಳಾಸ: 127.0.0.1 ದೂರದ ಬದಿಯಲ್ಲಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸೇವೆಗೆ ಸಂಪರ್ಕ ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಿಂದ ಅಲ್ಲ, ಬ್ಯಾಸ್ಟಿಯನ್‌ನಿಂದ ತೆರೆಯುತ್ತದೆ. ಸ್ಥಳೀಯ ಶ್ರೋತೃವನ್ನು -L 127.0.0.1:8443:... ಎಂದು ಕಿರಿದಾಗಿ ಬಂಧಿಸಿ, ಆಕಸ್ಮಿಕವಾಗಿ ಸೇವೆಯನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಪ್ರಕಟಿಸದಂತೆ. ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ, ಕ್ಲೈಂಟ್‌ನ ಒಳ್ಳೆಯ ನಡವಳಿಕೆಯನ್ನು ನಂಬುವ ಬದಲು ಖಾತೆ ಏನನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದೆಂದು ಸೀಮಿತಗೊಳಿಸಿ. PermitOpen, AllowTcpForwarding local ಮತ್ತು GatewayPorts no ಡೀಫಾಲ್ಟ್ — ಸಾಮಾನ್ಯ ರಿಲೇಯನ್ನು ನಿರ್ದಿಷ್ಟ ಚಾನಲ್ ಆಗಿ ಪರಿವರ್ತಿಸುವ ಮೂರು ಸೆಟ್ಟಿಂಗ್‌ಗಳು.

ಒಪ್ಪಂದವು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಕಿರಿದಾಗಿದೆ. SSH ತನ್ನ ಸ್ವಂತ ಚಾನಲ್ ರಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಬ್ಯಾಸ್ಟಿಯನ್‌ನಿಂದ ಇನ್ನೊಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಮುಂದಿನ ಹಾಪ್ ತನ್ನದೇ ರಕ್ಷಣೆ ಬೇಕು. ಬ್ಯಾಸ್ಟಿಯನ್‌ನ loopback ನಲ್ಲಿ ಮಾತ್ರ ಕೇಳುವ ಸೇವೆಯ ಮಾನ್ಯತೆ ಬೇರೆ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ತಲುಪುವ ಸೇವೆಗಿಂತ ಸಂಪೂರ್ಣ ಭಿನ್ನ, ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಸುರಂಗವನ್ನು ಅವುಗಳ ಬದಲಿಯಾಗಿ ಪರಿಗಣಿಸುವ ಬದಲು ಅಪ್ಲಿಕೇಶನ್‌ನ ದೃಢೀಕರಣ ಮತ್ತು TLS ಪರಿಶೀಲನೆಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ.

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

ಹಂತ 3: ರೂಟಿಂಗ್ ನಿಜವಾದ ಅಗತ್ಯವೇ?

ಆ ಪಟ್ಟಿ ಚಿಕ್ಕ ಆಯ್ಕೆಯ ಪ್ರಾಮಾಣಿಕ ವೆಚ್ಚ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ತಂಡಗಳು ಕೊನೆಗೆ ಮರೆತುಹೋದ ಕೆಲವು ಹಿನ್ನೆಲೆ ಆಜ್ಞೆಗಳನ್ನು ನಿರ್ವಹಿಸಲ್ಪಟ್ಟ ಯಾವುದೋ ಒಂದಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತವೆ. ಬದಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ VPN ಅಲ್ಲ. ಅಗತ್ಯವು ಇನ್ನೂ ಒಂದು TCP ಪೋರ್ಟ್ ಆಗಿದ್ದರೆ, ದಾಖಲಿತ ಮಾಲೀಕರೊಂದಿಗೆ ಮೇಲ್ವಿಚಾರಣೆಯ ಫಾರ್ವರ್ಡ್ ಓವರ್‌ಲೇಗಿಂತ ಅಗ್ಗವಾಗಿ ನಡೆಯುತ್ತದೆ ಮತ್ತು ನೀವು ನೋಡಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ಸೊಬಗನ್ನು ಅಳೆಯುವ ಮೊದಲು ಕಾರ್ಯಾಚರಣೆಯ ಮಾಲೀಕತ್ವವನ್ನು ಅಳೆಯಿರಿ.

ರೂಟಿಂಗ್ ಅಗತ್ಯವಾದಾಗ ರೂಟಿಂಗ್ ಸರಿಯಾದ ಉತ್ತರವಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯ IP ಸಂಪರ್ಕ ಅಗತ್ಯವಿರುವ ಹಲವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, TCP ಫಾರ್ವರ್ಡ್ ಸಾಗಿಸಲಾಗದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು, ಅಥವಾ ಹೋಸ್ಟ್‌ಗಳ ನಡುವೆ ಚಲಿಸುವ ಸೇವೆಗಳು — ಎಲ್ಲವೂ ಒಂದೇ ದಿಕ್ಕನ್ನು ತೋರಿಸುತ್ತವೆ.

ಓವರ್‌ಲೇ ಭಾಗವಹಿಸುವವರಿಗೆ ವಿಳಾಸ ಮತ್ತು ಮಾರ್ಗ ನೀಡುತ್ತದೆ, ನಂತರ ನಿಜವಾದ ಕೆಲಸ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ: ಅತಿವ್ಯಾಪಿಸದ ಶ್ರೇಣಿಗಳು, ಮಾರ್ಗ ಮಾಲೀಕತ್ವ, DNS, ನೋಂದಣಿ, ರದ್ದತಿ ಮತ್ತು ಸಹವರ್ತಿ ಕಣ್ಮರೆಯಾದಾಗ ಏನಾಗುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ವಿಳಾಸದೊಂದಿಗೆ ಬರುವುದಿಲ್ಲ. ಓವರ್‌ಲೇಗೆ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟ ಸಹವರ್ತಿ ಸಹ ಗಮ್ಯಸ್ಥಾನದ ಪ್ರತಿ ಕಾರ್ಯಾಚರಣೆಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಧಿಕೃತನಲ್ಲ, ಆದ್ದರಿಂದ ಸೇವಾ-ಹಂತದ ದೃಢೀಕರಣ ಉಳಿಯುತ್ತದೆ.

ನಂತರ ನಿಮ್ಮ ಬಳಿ ಏನಿದೆ

ನೀವು ಬಿಡುವ ದಾಖಲೆಗೆ ಎರಡು ವಿಷಯಗಳು ಸೇರುತ್ತವೆ. ಮೊದಲನೆಯದು ಕ್ಲೈಂಟ್ ಪರಿಶೀಲಿಸಬೇಕಾದ ಗುರುತು, ಏಕೆಂದರೆ ಏನನ್ನಾದರೂ ಕೆಲಸ ಮಾಡಿಸಲು ಹೆಸರಿನ ಪರಿಶೀಲನೆ ಸಡಿಲವಾದಾಗ ಈ ಪ್ರತಿಯೊಂದು ಗಡಿಯೂ ಮೌನವಾಗಿ ಕ್ಷೀಣಿಸುತ್ತದೆ. ಎರಡನೆಯದು ತೆಗೆಯುವ ಹಂತ: ಪ್ರವೇಶ ಮುಗಿದಾಗ ಯಾವ ಕೀ, ಯಾವ ನಿಯಮ ಅಥವಾ ಯಾವ ಮಾರ್ಗ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಯಾರು ಮಾಡುತ್ತಾರೆ.

ಈ ನಡಿಗೆ ಪ್ರಾರಂಭವಾದಲ್ಲೇ, ಸೇವೆಯಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ. ನಿಜವಾದ ಸಂಚಾರವನ್ನು ಆವರಿಸುವ ಮತ್ತು ನೀವು ಪರಿಶೀಲಿಸಲು ಉದ್ದೇಶಿಸಿದ ಸಹವರ್ತಿಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಗಡಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ನಂತರ ಪ್ರವೇಶವನ್ನು ಹೇಗೆ ನವೀಕರಿಸಲಾಗುತ್ತದೆ, ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ. OpenSSH ಉಲ್ಲೇಖ ಕಿರಿದಾದ ಒಪ್ಪಂದವನ್ನು ಭರವಸೆ ನೀಡುವ ಮೊದಲು ಫಾರ್ವರ್ಡಿಂಗ್ ಆಯ್ಕೆಗಳನ್ನು ದೃಢೀಕರಿಸುವ ಸ್ಥಳ. ತೆಗೆಯುವ ಹಂತವನ್ನು ಒಂದು ವಾಕ್ಯದಲ್ಲಿ ವಿವರಿಸಲಾಗದಿದ್ದರೆ, ಗಡಿ ಸಮಸ್ಯೆಗಿಂತ ದೊಡ್ಡದು.