Squid ಮೂಲಕ ಒಂದು VPN ಎಂಡ್‌ಪಾಯಿಂಟ್: ಸೀಮಿತ CONNECT ವಿನಾಯಿತಿ

ಒಂದು ಅನುಮೋದಿತ ಮೂಲವು ಪೋರ್ಟ್ 1194 ನಲ್ಲಿ ಒಂದು VPN ಗೇಟ್‌ವೇಗೆ Squid ಮೂಲಕ ತಲುಪಲು ಬಿಡಿ, ಜಾಗತಿಕ ಪೋರ್ಟ್ ಗಾರ್ಡ್‌ಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ ಮತ್ತು ಬೇರೆ ಏನೂ ತೆರೆಯಲಿಲ್ಲ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ.

Squid ಒಂದು CONNECT ವಿನಂತಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಮೊದಲ http_access ಸಾಲಿನಿಂದ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಸಾಲು ನಿರಾಕರಣೆಯೂ ಆಗಿರಬಹುದು. ಈ ಒಂದೇ ಸಂಗತಿಯು VPN ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಇರುವ ವಿನಾಯಿತಿ ಸಾಮಾನ್ಯವಾಗಿ ಮೊದಲ ಪ್ರಯತ್ನದಲ್ಲೇ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ವಿನಂತಿಯು ಕೆಳಭಾಗದಲ್ಲಿ ಯಾರೋ ಸೇರಿಸಿದ ಅನುಮತಿಯನ್ನು ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ. ಸೀಮಿತ ಪರಿಹಾರವು ಇರುವ ಪೋರ್ಟ್ ಗಾರ್ಡ್‌ಗಳನ್ನು ಉಳಿಸಿಕೊಂಡು ಅವುಗಳಿಗೆ ಒಂದು ಪರಿಶೀಲಿತ ಮೂಲ, ಗಮ್ಯ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಕಲಿಸುತ್ತದೆ. ಪ್ರಾಕ್ಸಿಯಲ್ಲಿನ ಉಳಿದೆಲ್ಲವೂ ಹಿಂದಿನಂತೆಯೇ ವರ್ತಿಸುತ್ತದೆ.

Squid ಒಂದು CONNECT ವಿನಂತಿಯನ್ನು ಹೇಗೆ ನಿರ್ಧರಿಸುತ್ತದೆ

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

ಸಾಂಪ್ರದಾಯಿಕ ಗಾರ್ಡ್‌ಗಳು Safe_ports ಹೊರಗಿನ ಎಲ್ಲವನ್ನೂ ನಿರಾಕರಿಸುತ್ತವೆ ಮತ್ತು SSL_ports ಹೊರಗಿನ CONNECT ಅನ್ನು ನಿರಾಕರಿಸುತ್ತವೆ. ಆ ಹೆಸರುಗಳು ನಿಮ್ಮ ಸ್ವಂತ ಸಂರಚನೆಯಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ACLಗಳು, ಆದ್ದರಿಂದ ಅವುಗಳ ವಿಷಯ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಅಲ್ಲ, ನಿಮಗೆ ಸೇರಿದ್ದು. ವಿತರಣೆಯು Safe_ports ಆಗಿ ವಿಶಾಲ ಪೋರ್ಟ್ ಶ್ರೇಣಿಯನ್ನು ಅನುಮತಿಸಿ CONNECT ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಮಿತಿಗೊಳಿಸಬಹುದು. ಪೋರ್ಟ್ ವಿನ್ಯಾಸದಿಂದ ನಿರ್ಬಂಧಿತವಾಗಿದೆ ಎಂದು ಭಾವಿಸುವ ಮೊದಲು ಜೀವಂತ ಮೌಲ್ಯಗಳನ್ನು ಓದಿ.

ವಿನಂತಿಯನ್ನು ನಿರಾಕರಿಸುತ್ತಿರುವ ಘಟಕ ಪ್ರಾಕ್ಸಿಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ. Squid ಉತ್ಪಾದಿಸುವ 403, VPN ಸರ್ವರ್‌ನ TLS ಎಚ್ಚರಿಕೆಗೆ ಸ್ವಲ್ಪವೂ ಹೋಲುವುದಿಲ್ಲ, ಮತ್ತು ಎರಡನ್ನೂ ಒಂದೇ ಸಮಸ್ಯೆಯಾಗಿ ಸೇರಿಸುವುದು ಮೊದಲ ಗಂಟೆಯನ್ನು ತಿನ್ನುತ್ತದೆ. ವಿನಂತಿಯ ಪ್ರವೇಶ ಲಾಗ್ ಸಾಲನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಅದು ಕ್ರಿಯೆ ಮತ್ತು ಅದನ್ನು ಉಂಟುಮಾಡಿದ ನಿಯಮ ಎರಡನ್ನೂ ದಾಖಲಿಸುತ್ತದೆ.

ಮೂರು ಪ್ರತ್ಯೇಕ ACL ಬದಲು ಒಂದು ಸಂಯೋಜಿತ ಹೊಂದಿಕೆ ನಿರ್ಮಿಸಿ

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

ಕೆಳಗಿನ ರೂಪವು ಪರಿಶೀಲಿತ ಮೌಲ್ಯಗಳಿಂದ ಬದಲಾಯಿಸಬೇಕಾದ ದಸ್ತಾವೇಜು ಶ್ರೇಣಿಗಳನ್ನು ಬಳಸುತ್ತದೆ. Squid ಈ ಹೆಸರುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ತನಗಾಗಿ ಕಾಯ್ದಿರಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಮತ್ತು ಸ್ಥಿರವಾಗಿ ಇರಿಸುವುದು ನಿಮ್ಮ ಕೆಲಸ. ಈ ವಿಧಾನವು all-of ಗುಂಪನ್ನು ಬೆಂಬಲಿಸುವ ದಸ್ತಾವೇಜಿತ ಸಂರಚನೆಯಿರುವ Squid 6 ಮತ್ತು 7 ಗೆ ಸೀಮಿತವಾಗಿದೆ. ಪ್ರಸ್ತುತ ಉಲ್ಲೇಖವು ಆ ಸೂಚನೆಗಳನ್ನು Squid 8 ನಲ್ಲಿ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ಗುರುತಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದನ್ನು ಸ್ಥಳಾಂತರಣ ಮಾರ್ಗವಲ್ಲದೆ ಆವೃತ್ತಿ-ಬದ್ಧ ವಿಧಾನವೆಂದು ಪರಿಗಣಿಸಿ, ಮತ್ತು ಅನ್ವಯಿಸುವ ಮೊದಲು ನಿಮ್ಮದೇ ಆವೃತ್ತಿಯ ಉಲ್ಲೇಖದಲ್ಲಿ ಸೂಚನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

all-of ಗುಂಪು ಪ್ರತಿ ಸದಸ್ಯನೂ ಹೊಂದಿಕೆಯಾದಾಗ ಮಾತ್ರ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ, ಅಂದರೆ ಮೂಲ, ಗಮ್ಯ ಮತ್ತು ಪೋರ್ಟ್ ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ. ಗುಂಪು ತಾನೇ ಏನನ್ನೂ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಮೂರು ಸಂಗತಿಗಳಲ್ಲಿ ಎರಡಕ್ಕೆ ಮಾತ್ರ ಹೊಂದಿಕೆಯಾಗುವ ವಿನಂತಿ ಅದನ್ನು ತೃಪ್ತಿಪಡಿಸಲಾರದು. ಈ ಗುಣವು ನಂತರ ಯಾರಾದರೂ ಎರಡನೇ ಗೇಟ್‌ವೇ ಸೇರಿಸಿದಾಗ ವಿನಾಯಿತಿಯನ್ನು ಸೀಮಿತವಾಗಿ ಇರಿಸುತ್ತದೆ. ಒಂದೋ ಹೊಸ ಗಮ್ಯವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಅಥವಾ ವಿನಂತಿ ಮೂಲ ಗಾರ್ಡ್‌ಗಳಿಗೆ ಮರಳುತ್ತದೆ.

ಪೋರ್ಟ್ ಗಾರ್ಡ್‌ಗಳನ್ನು ತೆಗೆಯದೆ ಬಗ್ಗಿಸಿ

ಅವುಗಳ ಪ್ರಸ್ತುತ ಸ್ಥಾನಗಳಲ್ಲಿ, ಎರಡು ಸಾಂಪ್ರದಾಯಿಕ ಗಾರ್ಡ್ ಸಾಲುಗಳು ಹೀಗೆ ಕಾಣುತ್ತವೆ. ಅವು ಸಾಮಾನ್ಯವಾಗಿ ದೃಢೀಕರಣದ ನಂತರ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಅನುಮತಿಸುವ ನೀತಿ ಸಾಲುಗಳ ಮೊದಲು ಇರುತ್ತವೆ.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

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

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

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

ವಿನಾಯಿತಿಯನ್ನು ಎಲ್ಲಿ ಇಡಬಾರದು

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

ಪೋರ್ಟ್ ಗಾರ್ಡ್‌ಗಳ ನಂತರ ವಿನಂತಿಗೆ ಇನ್ನೂ ಏನು ಬೇಕು ಎಂದು ಪರಿಶೀಲಿಸಿ. ದೃಢೀಕೃತ ಖಾತೆ, ಅನುಮತಿಸಿದ ಕ್ಲೈಂಟ್ ವಿಳಾಸ ಮತ್ತು ಗಮ್ಯ ನೀತಿ ಎಲ್ಲವೂ ಇನ್ನೂ ಅನ್ವಯಿಸುತ್ತವೆ, ಮತ್ತು ವಿನಾಯಿತಿ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಪ್ರಾಕ್ಸಿ ಅನುಮೋದಿತ ಖಾತೆಗೆ ಈಗಾಗಲೇ ಅನಿಯತ ಗಮ್ಯಗಳನ್ನು ತಲುಪಲು ಬಿಡುತ್ತಿದ್ದರೆ, ಪೋರ್ಟ್ ಗಾರ್ಡ್ ಎಂದಿಗೂ ನಿಜವಾದ ನಿಯಂತ್ರಣವಾಗಿರಲಿಲ್ಲ.

ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸ್ವಲ್ಪವಾದರೂ TCP ಆಗಿದೆಯೇ ಎಂದು ಯೋಚಿಸಿ. CONNECT ವಿನಾಯಿತಿ TCP ಹರಿವುಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು UDP ಬಳಸುವ OpenVPN ಪ್ರೊಫೈಲ್ ಅದರ ಮೂಲಕ ತಲುಪಬಹುದಾದದ್ದಾಗುವುದಿಲ್ಲ. ಸರ್ವರ್ ಹಾಗೆ ಆಲಿಸಿದರೆ ಮತ್ತು ನಿರ್ವಾಹಕರು ವರ್ತನೆಯ ವ್ಯತ್ಯಾಸವನ್ನು ಒಪ್ಪಿದರೆ ಮಾತ್ರ ಪ್ರೊಫೈಲ್ ಅನ್ನು TCP ಗೆ ಬದಲಾಯಿಸಿ.

ಪಾರ್ಸರ್ ಮತ್ತು ನಿಜವಾದ ವಿನಂತಿಯೊಂದಿಗೆ ಗಡಿಯನ್ನು ಪರಿಶೀಲಿಸಿ

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

ನಂತರ ಮತ್ತೆ ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಅನುಮೋದಿತ ಮೂಲದಿಂದ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಒಂದು ನಿಜವಾದ CONNECT ಕಳುಹಿಸಿ. ಪಾರ್ಸರ್ ಚಲಾಯಿಸುವುದು ಮೊದಲು ಬರುತ್ತದೆ, ಏಕೆಂದರೆ ಟೈಪಿಂಗ್ ತಪ್ಪಿನೊಂದಿಗೆ ಮತ್ತೆ ಲೋಡ್ ಮಾಡುವುದು ನೀತಿಯ ಬಗ್ಗೆ ನಿಮಗೆ ಏನನ್ನೂ ಕಲಿಸುವುದಿಲ್ಲ.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು