HTTP ಪ್ರಾಕ್ಸಿ, SSH ಸುರಂಗ ಅಥವಾ VPN: ಸರಿಯಾದ ಪದರವನ್ನು ಆಯ್ಕೆಮಾಡಿ

ಆಂತರಿಕ ಸೇವೆಗೆ ಹೇಗೆ ತಲುಪುವುದು ಎಂದು ಮೂವರು ಇಂಜಿನಿಯರ್ಗಳನ್ನು ಕೇಳಿ, ಮೂರು ವಿನ್ಯಾಸಗಳು ಸಿಗುತ್ತವೆ: ವೆಬ್ ಪ್ರಾಕ್ಸಿ, SSH ಸುರಂಗ ಅಥವಾ ಪೂರ್ಣ VPN। ಮೂರೂ ದೂರದ ಸೇವೆಯನ್ನು ಕೈಗೆಟುಕುವಂತೆ ಮಾಡಬಲ್ಲವು ಮತ್ತು ಮೂರೂ ಸಂಚಾರವು ಬೇರೆಡೆಯಿಂದ ಬರುತ್ತಿರುವಂತೆ ತೋರಿಸಬಲ್ಲವು। ವ್ಯತ್ಯಾಸಗಳು ನಂತರ ಕಾಣಿಸುತ್ತವೆ, ಬಳಸುತ್ತಿರುವ ಪ್ರೋಟೋಕಾಲ್ ಆಯ್ದ ಸಾಧನ ಊಹಿಸುವುದಕ್ಕಿಂತ ಬೇರೆಯಾದಾಗ। ಬ್ರೌಸರ್ನಲ್ಲಿನ ತ್ವರಿತ ಪರಿಶೀಲನೆ ಯಶಸ್ವಿಯಾದ ವಿನ್ಯಾಸವು ವಿನಂತಿಗೆ ಕಾರಣವಾದ ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ನಿಯಮಿತವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ।

ಎರಡು ಸಂಗತಿಗಳಿಂದ ನಿರ್ಧರಿಸಿ: ಯಾವ ಪ್ರೋಟೋಕಾಲ್ಗಳು ದಾಟಬೇಕು ಮತ್ತು ಸಂಬಂಧಿತ ಹೆಸರುಗಳನ್ನು ಯಾರು ವಿಶ್ಲೇಷಿಸಬಲ್ಲರು। ಉಳಿದದ್ದು ಆದ್ಯತೆ।

ಪ್ರಾಕ್ಸಿ ತನಗೆ ಅರ್ಥವಾದದ್ದನ್ನು ಮಾತ್ರ ಸರಿಸುತ್ತದೆ

ವೆಬ್ ಪ್ರಾಕ್ಸಿ ತನಗಾಗಿ ನಿರ್ಮಿಸಿದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತದೆ। ಕ್ಲೈಂಟ್ ಅದಕ್ಕೆ ವಿನಂತಿ ನೀಡುತ್ತದೆ ಮತ್ತು ಅದು ಆ ವಿನಂತಿಯನ್ನು ಮುಂದೆ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಇಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪೂರ್ಣವಾಗಿ ಭಾಗವಹಿಸುವುದಿಲ್ಲ। HTTPS ಗೆ ಕ್ಲೈಂಟ್ಗೆ ಅಪಾರದರ್ಶಕ ಚಾನಲ್ ಬೇಕು, ಅದನ್ನು ಪ್ರಾಕ್ಸಿ ವಿನಂತಿ ಓದುವ ಬದಲು CONNECT ಮೂಲಕ ಒದಗಿಸುತ್ತದೆ।

SSH ಕ್ರಿಯಾತ್ಮಕ ಫಾರ್ವರ್ಡ್ SOCKS ಮಾತನಾಡುವ ಸ್ಥಳೀಯ ಪೋರ್ಟ್ ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಆ ಪೋರ್ಟ್ TCP ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಕ್ಲೈಂಟ್ ಹೆಸರಿಸುವ ಯಾವುದೇ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ರವಾನಿಸುತ್ತದೆ। TCP ಮೇಲೆ ನಿರ್ಮಿಸಿದ ಪ್ರೋಟೋಕಾಲ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅದರ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತವೆ। UDP ಆಗುವುದಿಲ್ಲ, ಸಾಧನವು ಸ್ಪಷ್ಟವಾಗಿ ಬೆಂಬಲ ಸೇರಿಸದಿದ್ದರೆ। ಸ್ಥಳೀಯ ಫಾರ್ವರ್ಡ್ ಇನ್ನೂ ಸಂಕುಚಿತ: ಒಂದು ಸ್ಥಳೀಯ ಪೋರ್ಟ್ ಒಂದು ಸ್ಥಿರ ಹೋಸ್ಟ್ ಮತ್ತು ಪೋರ್ಟ್ಗೆ ನಕ್ಷೆ ಮಾಡಲಾಗಿದೆ, ಅದು ಒಂದು ತಿಳಿದ ಸೇವೆಗೆ ಮಾತ್ರ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ।

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸರಿಸುತ್ತದೆ। ಕ್ಲೈಂಟ್ ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸುವ ಎಲ್ಲವೂ ಅದರ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ, UDP ಮತ್ತು ICMP ಸೇರಿದಂತೆ, ಆದ್ದರಿಂದ ಅದು ಒಂದೇ ಸಂಪರ್ಕಕ್ಕಲ್ಲ, ಜಾಲದ ಅಗತ್ಯಕ್ಕೆ ಸರಿಹೊಂದುತ್ತದೆ।

ಯಾರೋ ಹೆಸರನ್ನು ವಿಶ್ಲೇಷಿಸಬೇಕು

ಗುರಿ ಹೆಸರು ದೂರದ ಜಾಲದ DNS ನಲ್ಲಿ ಮಾತ್ರ ಇದ್ದಾಗ, ಹುಡುಕಾಟ ಮಾಡುವ ಯಂತ್ರವು ಆ ವಲಯವನ್ನು ನೋಡಲು ಸಾಧ್ಯವಾಗಬೇಕು। ವೆಬ್ ಪ್ರಾಕ್ಸಿ ತಾನೇ ಹುಡುಕಾಟ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಲ್ಯಾಪ್ಟಾಪ್ ಹೆಸರನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವಿಶ್ಲೇಷಿಸಲಾಗದಿದ್ದರೂ ಆಂತರಿಕ ಹೆಸರು ಅದರ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ। SOCKS ಕೂಡ ಹಾಗೆಯೇ ವರ್ತಿಸಬಹುದು, ಆದರೆ ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ವಿಶ್ಲೇಷಿಸಿದ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಿಸುವ ಬದಲು ಹೆಸರನ್ನು ರವಾನಿಸಿದರೆ ಮಾತ್ರ। ಆ ಆಯ್ಕೆ ಸರ್ವರ್ನಲ್ಲಲ್ಲ, ಕ್ಲೈಂಟ್ನಲ್ಲಿದೆ।

curl ವಿಭಜನೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸುತ್ತದೆ: ಒಂದು ಫ್ಲ್ಯಾಗ್ ಹೋಸ್ಟ್ಹೆಸರನ್ನು ಪ್ರಾಕ್ಸಿಗೆ ನೀಡುತ್ತದೆ, ಇನ್ನೊಂದು ಮೊದಲು ಸ್ಥಳೀಯವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತದೆ। ಸ್ಥಳೀಯ ವಿಶ್ಲೇಷಣೆಯಲ್ಲಿ ಆಂತರಿಕ ಹೆಸರು ಯಾವುದೇ ಸುರಂಗವನ್ನು ತಾಗುವ ಮೊದಲೇ ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು ದೋಷವು ವಾಸ್ತವವಾಗಿ DNS ನಿರ್ಧಾರವಾಗಿದ್ದದ್ದಕ್ಕೆ ಪ್ರಾಕ್ಸಿಯನ್ನು ದೂಷಿಸುತ್ತದೆ।

VPN ಮೂರನೇ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: ಮಾರ್ಗಗಳ ಪಕ್ಕದಲ್ಲಿ ಖಾಸಗಿ ವಿಶ್ಲೇಷಕ ಮತ್ತು ಹುಡುಕಾಟ ಡೊಮೇನ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ। ಅದು ಅನುಕೂಲಕರ ಮತ್ತು ಪರಿಚಿತ ಭ್ರಮೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ: ಉತ್ತರಿಸದ ವಿಶ್ಲೇಷಕದೊಂದಿಗೆ ಇರುವ ಮಾರ್ಗವು ಪ್ಯಾಕೆಟ್ಗಳು ಆಚೆಗೆ ತಲುಪುತ್ತಿದ್ದರೂ ಸತ್ತ ಸುರಂಗದಂತೆಯೇ ಕಾಣುತ್ತದೆ।

ಜಾಲವು ಒಂದೇ ನಿರ್ಗಮನವನ್ನು ಅನುಮತಿಸಿದಾಗ

ಅನೇಕ ಸಂಸ್ಥೆಗಳ ಜಾಲಗಳು ಹೊರಹೋಗುವ ಸಂಪರ್ಕಗಳನ್ನು ದೃಢೀಕೃತ ವೆಬ್ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಮಾತ್ರ ಅನುಮತಿಸುತ್ತವೆ। OpenVPN ಮತ್ತು SSH ಎರಡನ್ನೂ ಅಲ್ಲಿ ಕೆಲಸ ಮಾಡಿಸಬಹುದು, ಮೊದಲನೆಯದು ತನ್ನ ಸಾಗಣೆಯನ್ನು ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಸುರಂಗ ಮಾಡಿ, ಎರಡನೆಯದು ಸಣ್ಣ CONNECT ಸಹಾಯಕವನ್ನು ನಡೆಸುವ ಪ್ರಾಕ್ಸಿ ಆದೇಶದ ಮೂಲಕ।

TCP ಮೇಲೆ ನಿರ್ಮಿಸಿದ ಸುರಂಗಗಳು ಆ ನಿರ್ಬಂಧವನ್ನು ತಡೆದುಕೊಳ್ಳುತ್ತವೆ, UDP ಆಧಾರಿತ VPN ತಡೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಇದು ಮನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಕಚೇರಿಯಲ್ಲಿ ವಿಫಲವಾಗುವ ಅನೇಕ ಸಂರಚನೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ। ಎರಡನೇ ವೆಚ್ಚವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು ಸುಲಭ: ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಹೋಗುವ TCP ಸಂಪರ್ಕದೊಳಗೆ ಸಾಗಿಸುವ TCP ಸುರಂಗವು ಈಗ ಮರುಕಳುಹಿಸುವ ಎರಡು ಪದರಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ನಷ್ಟದ ಸಂದರ್ಭದಲ್ಲಿ ಆ ಜೋಡಿ ಯಾವುದೇ ಒಂದು ಪದರವೂ ಒಂಟಿಯಾಗಿ ಉಂಟುಮಾಡದ ರೀತಿಯಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ।

ಮಧ್ಯವರ್ತಿಗಳನ್ನು ಸರಪಳಿಗೊಳಿಸುವುದು ಪದರವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದಕ್ಕಿಂತ ಬೇರೆ ಪ್ರಶ್ನೆ। ಎರಡನೇ ಪ್ರಾಕ್ಸಿ ಅಥವಾ Tor ಸೇರಿಸುವುದು ಯಾರು ಏನನ್ನು ಗಮನಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಸರಪಳಿಯಲ್ಲಿನ ಸ್ಥಾನವು ಯಾವ ಹಾಪ್ ಗೂಢಲಿಪಿ ಪಠ್ಯವನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ।

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

ನಕಲಿ ವಿಳಾಸವು ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದಲ್ಲ

ಬೇರೊಬ್ಬರ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸೃಷ್ಟಿಸುವುದು ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಸಾಧಿಸುವುದಿಲ್ಲ: ಉತ್ತರಗಳು ನಿಜವಾದ ಮಾಲೀಕರಿಗೆ ಹೋಗುತ್ತವೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಜಾಲಗಳು ಸಂಚಾರವನ್ನು ನೇರವಾಗಿ ಬಿಸಾಡುತ್ತವೆ। ಮಧ್ಯವರ್ತಿ ಬೇಕಾಗಿರುವುದು ಮೂಲವನ್ನು ಕಲ್ಪಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದ ಕಾರಣವೇ, ಮತ್ತು ಅದು ಮೂರೂ ವಿನ್ಯಾಸಗಳ ಪ್ರಾಮಾಣಿಕ ಸಮರ್ಥನೆ।

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

ಪ್ರೋಟೋಕಾಲ್ಗಳು ಮತ್ತು ಹೆಸರುಗಳಿಂದ ನಿರ್ಧರಿಸಿ

ಒಂದೇ ವೆಬ್ ಕ್ಲೈಂಟ್ಗೆ ಒಂದೇ ವೆಬ್ ಸೇವೆ ಬೇಕಾದಾಗ ಮತ್ತು ಅದಕ್ಕೆ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ಗಳಿದ್ದಾಗ ಪ್ರಾಕ್ಸಿ ಆಯ್ಕೆಮಾಡಿ। ಕೆಲವು ತಿಳಿದ TCP ಸೇವೆಗಳು ಸಾಕಾದಾಗ ಮತ್ತು SSH ಪ್ರವೇಶ ಈಗಾಗಲೇ ಇದ್ದಾಗ SSH ಸುರಂಗ ಆಯ್ಕೆಮಾಡಿ। ಹಲವು ಅಪ್ಲಿಕೇಶನ್ಗಳು, TCP ಅಲ್ಲದ ಸಂಚಾರ, ಖಾಸಗಿ DNS ಅಥವಾ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಮಾರ್ಗ ಅಗತ್ಯದ ಭಾಗವಾದಾಗ VPN ಆಯ್ಕೆಮಾಡಿ।

ನಂತರ ನಿಜವಾದ ಕ್ಲೈಂಟ್ ಮತ್ತು ನಿಜವಾದ ಹೆಸರಿನೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ। ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಪುಟ ಲೋಡ್ ಮಾಡುವುದು UDP ಬಗ್ಗೆ ಏನನ್ನೂ ಕಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ಒಂದು ಸಾಧನವನ್ನು SOCKS ಮೇಲೆ ನಡೆಸುವುದು ಸಿಸ್ಟಮ್ ವಿಶ್ಲೇಷಕದ ಬಗ್ಗೆ ಏನನ್ನೂ ಕಲಿಸುವುದಿಲ್ಲ। ಪ್ರಕ್ರಿಯೆಯು ಯಾವ ಸ್ಥಳೀಯ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಯಾಯಿತು ಮತ್ತು ಯಾವ ವಿಶ್ಲೇಷಕ ಉತ್ತರಿಸಿತು ಎಂಬುದನ್ನು ಓದಿ। ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗ ಮತ್ತು ಒಮ್ಮೆ ಆಕಸ್ಮಿಕವಾಗಿ ಕೆಲಸ ಮಾಡಿದ ಮಾರ್ಗದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಇದೇ।