TLS ನಿಯಂತ್ರಣ ಚಾನೆಲ್‌ನ ಒಳಗೆ ಸಾಗುತ್ತದೆ, ಇಡೀ ಸುರಂಗದಲ್ಲಿ ಅಲ್ಲ

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

ಹೊದಿಕೆ ಮೊದಲು ಬರುತ್ತದೆ

ಪ್ರತಿ ಸುರಂಗ ಪ್ಯಾಕೆಟ್ ಪ್ರೋಟೋಕಾಲ್‌ನ ಸ್ವಂತ ಹೆಡರ್‌ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ: ಸಂದೇಶ ಪ್ರಕಾರ, ಕೀ ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಬೈಟ್-ಸ್ಟ್ರೀಮ್ ಸಾಗಣೆಯಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಗುರುತಿಸುವ ಉದ್ದದ ಪೂರ್ವಪ್ರತ್ಯಯ. ಆ ಹೊದಿಕೆಯನ್ನು ವಿಶ್ಲೇಷಿಸದ ಓದುಗನಿಗೆ ಮುಂದಿನ ಕ್ಷೇತ್ರ ಎಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂದು ತಿಳಿಯದು.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

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

ವಿಶ್ವಾಸಾರ್ಹತೆ ಪದರ ಪ್ರೋಟೋಕಾಲ್‌ನದೇ

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

ಪ್ರಯೋಜನವೆಂದರೆ ಹೊರಗಿನ ಸಾಗಣೆ UDP ಆಗಿದ್ದರೂ TLS ಕೈಕುಲುಕುವಿಕೆಗೆ ವಿಶ್ವಾಸಾರ್ಹ ವಾಹಕ ಸಿಗುತ್ತದೆ. ಬೆಲೆಯೆಂದರೆ ಒಂದು ಡೇಟಾಗ್ರಾಮ್ ಆ ಸಂಭಾಷಣೆಯ ಒಂದು ಭಾಗವನ್ನು ಮಾತ್ರ ಹೊಂದಿರಬಹುದು, ಆದ್ದರಿಂದ ಅದನ್ನು ಸ್ವತಂತ್ರ TLS ದಾಖಲೆಯಾಗಿ ಪರಿಗಣಿಸುವುದು ಅಸಂಬದ್ಧತೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಮರುಜೋಡಣೆ ಪ್ರೋಟೋಕಾಲ್ ಪದರದಲ್ಲೇ ನಡೆಯಬೇಕು. ಆದ್ದರಿಂದ ಸೆರೆಹಿಡಿದ ಪ್ಯಾಕೆಟ್ ಪೂರ್ಣ ಕೈಕುಲುಕುವಿಕೆ ಹಂತದಂತೆ ಅಪರೂಪವಾಗಿ ಕಾಣುತ್ತದೆ.

ಹೊರಗಿನ ಸಾಗಣೆಯನ್ನು TCP ಗೆ ಬದಲಾಯಿಸುವುದು ಈ ಪದರವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ. ವಿಶ್ವಾಸಾರ್ಹ ಸಾಗಣೆ ಎಂದರೆ ಪ್ರೋಟೋಕಾಲ್ ಮಟ್ಟದಲ್ಲಿ ಕಡಿಮೆ ಮರುಪ್ರೇಷಣೆ, ಫ್ರೇಮಿಂಗ್ ಮಾಯವಾಗುವುದು ಅಥವಾ ಸಂಚಾರ HTTP ಆಗುವುದು ಎಂದಲ್ಲ.

ಡೇಟಾ ಪ್ಯಾಕೆಟ್‌ಗಳು ಬೇರೆ ಸ್ವರೂಪವನ್ನು ಬಳಸುತ್ತವೆ

ಅಧಿವೇಶನ ಇದ್ದಾಗ, ಉಪಯುಕ್ತ ಪೇಲೋಡ್ ಒಳಗಿನ IP ಪ್ಯಾಕೆಟ್‌ಗಳು ಅಥವಾ Ethernet ಫ್ರೇಮ್‌ಗಳನ್ನು ಹೊತ್ತ ಡೇಟಾ ಸಂದೇಶಗಳಾಗಿ ಬರುತ್ತದೆ. ಅವು ತಮ್ಮದೇ ಕೀಗಳು ಮತ್ತು ತಮ್ಮದೇ ಸಂಸ್ಕರಣೆಯಿಂದ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿವೆ, ಮತ್ತು TLS ಗ್ರಂಥಾಲಯವು ಸ್ವೀಕರಿಸುವ ಯಾವುದೇ ಅರ್ಥದಲ್ಲಿ ಅವು TLS ಅನ್ವಯ ದಾಖಲೆಗಳಲ್ಲ.

ಆ ಬೇರ್ಪಡಿಕೆ ಸಂರಚನೆಯಲ್ಲಿ ಕಾಣುತ್ತದೆ: ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ಮತ್ತು ಡೇಟಾ ಚಾನೆಲ್‌ಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಸೈಫರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆ, ಆದ್ದರಿಂದ ಒಂದನ್ನು ಹೆಸರಿಸುವ ಲಾಗ್ ಸಾಲು ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಬಲವಾದ ನಿಯಂತ್ರಣ ಸೈಫರ್ ಅನ್ನು ಬಲವಾದ ಡೇಟಾ ಸೈಫರ್‌ನ ಸಾಕ್ಷಿಯಾಗಿ ಓದುವುದು ಸಾಮಾನ್ಯ ವರದಿ ದೋಷ.

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

HTTPS ಪ್ರಾಕ್ಸಿ ಏಕೆ ಸಹಾಯ ಮಾಡಲಾರದು

TLS ಅನ್ನು ಮುಗಿಸುವ ಪ್ರಾಕ್ಸಿ TLS ದಾಖಲೆಗಳ ಹರಿವು ಮತ್ತು ನಂತರ ಅದರೊಳಗೆ ಅನ್ವಯ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. ಈ ಪ್ರೋಟೋಕಾಲ್‌ನ ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ತನ್ನದೇ ಫ್ರೇಮಿಂಗ್‌ನೊಳಗೆ, ಸುತ್ತಲೂ ವಿಶ್ವಾಸಾರ್ಹತೆ ಪದರದೊಂದಿಗೆ ಸಾಗಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಮುಗಿಸುವ ಪ್ರಾಕ್ಸಿ ಆ ಫ್ರೇಮಿಂಗ್ ಅನ್ನು ಹಾಳಾದ ಇನ್‌ಪುಟ್ ಎಂದು ಓದುತ್ತದೆ.

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

ಜಾಡನ್ನು ಸರಿಯಾಗಿ ಓದುವುದು

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

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