SSH ಫಾರ್ವರ್ಡ್ ನಿಜವಾಗಿ ಯಾವ ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುತ್ತದೆ?

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

ಏನನ್ನೂ ಹೋಲಿಸುವ ಮೊದಲು ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿಸಿ

OpenSSH ಕ್ಲೈಂಟ್ ಕೈಪಿಡಿ ಗೊಂದಲಕ್ಕೀಡಾಗುವ ನಾಲ್ಕು ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಶೆಲ್ ಅಥವಾ ದೂರದ ಆಜ್ಞೆ SSH ಹೋಸ್ಟ್ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಸ್ಥಳೀಯ ಫಾರ್ವರ್ಡ್ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಆಲಿಸುವ ಸಾಕೆಟ್ ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಸಂಪರ್ಕವನ್ನು ದೂರದ ಬದಿಯಿಂದ ಮಾಡುತ್ತದೆ. ದೂರದ ಫಾರ್ವರ್ಡ್ ವಿರುದ್ಧವಾಗಿ ಮಾಡುತ್ತದೆ, ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಆಲಿಸುತ್ತದೆ. ಕ್ರಿಯಾಶೀಲ ಫಾರ್ವರ್ಡಿಂಗ್ ಅದನ್ನು ಬಳಸುವುದು ಹೇಗೆಂದು ತಿಳಿದಿರುವ ಪ್ರೋಗ್ರಾಮ್ಗಳಿಗೆ SOCKS ಅಂತ್ಯಬಿಂದುವನ್ನು ಒದಗಿಸುತ್ತದೆ.

• ಶೆಲ್: ಪ್ರೋಗ್ರಾಮ್ ದೂರದ ಯಂತ್ರದಲ್ಲಿ ಚಲಿಸುತ್ತದೆ, ಸ್ಥಳೀಯವಾಗಿ ಏನೂ ಆಲಿಸುವುದಿಲ್ಲ.
• ಸ್ಥಳೀಯ ಫಾರ್ವರ್ಡ್: ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಪೋರ್ಟ್ ಇದೆ, ದೂರದ ಹೋಸ್ಟ್ ಹೊರಹೋಗುವ ಸಂಪರ್ಕವನ್ನು ಮಾಡುತ್ತದೆ.
• ದೂರದ ಫಾರ್ವರ್ಡ್: ದೂರದ ಬದಿಯಲ್ಲಿ ಪೋರ್ಟ್ ಇದೆ, ಸಂಚಾರ ನಿಮ್ಮ ಕಡೆಗೆ ಮರಳುತ್ತದೆ.
• ಕ್ರಿಯಾಶೀಲ: ಕ್ಲೈಂಟ್ನಲ್ಲಿ SOCKS ಪ್ರಾಕ್ಸಿ, ಪ್ರಾಕ್ಸಿ ಅರಿವಿರುವ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಮಾತ್ರ ಬಳಸುತ್ತವೆ.

ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ. ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ, ಅಥವಾ UDP ಮಾತನಾಡುವ, ಅಥವಾ ಹೆಸರುಗಳನ್ನು ತಾನೇ ಪರಿಹರಿಸುವ ಪ್ರೋಗ್ರಾಮ್, ಸಕ್ರಿಯ SSH ಸೆಷನ್‌ನಿಂದ ಪ್ರಭಾವಿತವಾಗುವುದಿಲ್ಲ. ಇದು SSH ಯಲ್ಲಿ ದೋಷವಲ್ಲ; ಇದು ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ಇಂಟರ್ಫೇಸ್‌ನ ವ್ಯಾಪ್ತಿ.

ಸ್ಥಳೀಯ, ದೂರದ ಮತ್ತು ಕ್ರಿಯಾಶೀಲ ಫಾರ್ವರ್ಡ್ಗಳು ಯಾರು ಆಲಿಸುತ್ತಾರೆ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನ

ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳನ್ನು ನಿರ್ಧರಿಸುವ ವ್ಯತ್ಯಾಸ ಎಂದರೆ ಆಲಿಸುವ ಸಾಕೆಟ್ ಯಾರಿಗೆ ಸೇರಿದೆ ಎಂಬುದು. ಸ್ಥಳೀಯ ಫಾರ್ವರ್ಡ್ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಆಲಿಸುತ್ತದೆ ಮತ್ತು ದೂರದ ತುದಿ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಡಯಲ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸ ಸರ್ವರ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ. ದೂರದ ಫಾರ್ವರ್ಡ್ನಲ್ಲಿ ಸರ್ವರ್ ಆಲಿಸುತ್ತದೆ ಮತ್ತು ಸಂಪರ್ಕ ನಿಮ್ಮ ಬದಿಗೆ ಮರಳಿ ಸಾಗಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಹೀಗೆ ನೀವು ಸ್ಥಳೀಯ ಸೇವೆಯನ್ನು ನೇರವಾಗಿ ಪ್ರಕಟಿಸದೆ ಬಹಿರಂಗಪಡಿಸುತ್ತೀರಿ.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

ಮೊದಲ ಆಜ್ಞೆ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಪೋರ್ಟ್ 5432 ಅನ್ನು ಬಂಧಿಸಿ ಬ್ಯಾಸ್ಟಿಯನ್ನಿಂದ ಕಾಣುವಂತೆ ಡೇಟಾಬೇಸ್ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ. ಎರಡನೆಯದು ಪೋರ್ಟ್ 1080 ನಲ್ಲಿ SOCKS ಪ್ರಾಕ್ಸಿ ರಚಿಸುತ್ತದೆ. ಮೂರನೆಯ ಆಜ್ಞೆ ಯಾವ ಪ್ರಕ್ರಿಯೆಗಳು ನಿಜವಾಗಿ ಆಲಿಸುತ್ತಿವೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಪೋರ್ಟ್ ಘರ್ಷಣೆಯಿಂದ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗಿರುವ ಬದಲು ಫಾರ್ವರ್ಡ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂಬುದಕ್ಕೆ ಅದೇ ಏಕೈಕ ಸಾಕ್ಷ್ಯ.

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

ಸುರಂಗ-ಸಾಧನ ಮೋಡ್ ಏಕೈಕ ನಿಜವಾದ ನೆಟ್ವರ್ಕ್ ಅಪವಾದ

OpenSSH -w ಸುರಂಗ-ಸಾಧನ ಫಾರ್ವರ್ಡಿಂಗ್ ಅನ್ನೂ ಬೆಂಬಲಿಸುತ್ತದೆ, ಅದು TCP ಆಲಿಸುವವರ ಬದಲು ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ರವಾನಿಸುತ್ತದೆ. ಅದು ನಿಜವಾದ ನೆಟ್ವರ್ಕ್ ಸುರಂಗ, ಮತ್ತು ಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಂರಚಿಸಲಾಗುತ್ತದೆ, ಶೆಲ್ ತೆರೆಯುವ ಅಡ್ಡಪರಿಣಾಮವಲ್ಲ.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

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

ಆಗಲೂ ಸುರಂಗ ದೂರದ ಹೋಸ್ಟ್ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. SSH ಸಾಗಣೆ ಒದಗಿಸಿದ ಯಾವುದೇ ರಕ್ಷಣೆ ಅಲ್ಲಿಯೇ ಮುಗಿಯುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಸಂಪರ್ಕ ಪ್ರತ್ಯೇಕ ಜಿಗಿತ. VPN ಗೇಟ್ವೇ ಕೂಡ ಅದೇ ಆಕಾರದ ಗಡಿಯನ್ನು ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ಹೋಲಿಕೆ ಯಾವ ಸಾಧನ ಬಲಶಾಲಿ ಎಂಬುದರ ಬಗ್ಗೆ ಅಲ್ಲ, ವ್ಯಾಪ್ತಿ ಮತ್ತು ಅಂತ್ಯದ ಬಗ್ಗೆ ಇರಬೇಕು. ಆ ಗಡಿಯನ್ನು ಗಟ್ಟಿಯಾಗಿ ಹೆಸರಿಸುವುದು ಸುರಂಗ «ಎಲ್ಲವನ್ನೂ ಗೂಢಲಿಪೀಕರಿಸುತ್ತದೆ» ಎಂಬ ವಾದವನ್ನೂ ಬಗೆಹರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಸ್ಪಷ್ಟವಾಗಿ ಮಾಡುವುದಿಲ್ಲ.

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನೀವು ನಿರ್ಮಿಸಿದ ಇಂಟರ್ಫೇಸ್ ಬಳಸುತ್ತದೆಯೇ ಎಂದು ಪರೀಕ್ಷಿಸಿ

ಪರಿಶೀಲನೆ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ಗೆ, ಸೆಷನ್ಗೆ ಅಲ್ಲ. ಕೆಲಸ ಮಾಡುವ ಫಾರ್ವರ್ಡ್ ಪೋರ್ಟ್ ಬಂಧಿತವಾಗಿದೆ ಮತ್ತು ದೂರದ ಬದಿ ಡಯಲ್ ಮಾಡಬಹುದು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ನಿಮಗೆ ಮುಖ್ಯವಾದ ಪ್ರೋಗ್ರಾಮ್ ಅದರ ಮೂಲಕ ಸಂಪರ್ಕಿಸಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

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

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