ಪರ್ಲ್ SOCKS ಸಂಪರ್ಕ ತೆರೆದ ನಂತರ TLS ಸೇರಿಸಿ

SOCKS ಸಂಪರ್ಕ ಮತ್ತು TLS ಸಂಪರ್ಕದ ಕೆಲಸಗಳು ಬೇರೆ ಬೇರೆ. ಮೊದಲು SOCKS ಮೂಲಕ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಬೈಟ್ ಸ್ಟ್ರೀಮ್ ಪಡೆಯಿರಿ. ನಂತರ ಆ ಸ್ಟ್ರೀಮ್ ಮೇಲೆ TLS ಪ್ರಾರಂಭಿಸಿ, ಪ್ರಾಕ್ಸಿ ಅಲ್ಲ, ಗಮ್ಯಸ್ಥಾನದ ಜಾಲತಾಣವನ್ನು ಗುರುತಿಸಿ.

HTTPS ಶೈಲಿಯ TLS ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ವಿನ್ಯಾಸ ಹೀಗಿರಬಹುದು:

use IO::Socket::Socks;
use IO::Socket::SSL;

my $target = 'example.com';
my $socket = IO::Socket::Socks->new(
    SocksVersion => 5,
    ProxyAddr => '127.0.0.1',
    ProxyPort => 1080,
    ConnectAddr => $target,
    ConnectPort => 443,
) or die $!;

IO::Socket::SSL->start_SSL(
    $socket,
    SSL_hostname => $target,
    SSL_verifycn_name => $target,
    SSL_verifycn_scheme => 'http',
    SSL_verify_mode => SSL_VERIFY_PEER,
) or die IO::Socket::SSL::errstr();

ಅನುಮತಿಸಿದ ಸಾರ್ವಜನಿಕ-ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗದಲ್ಲಿರುವ ಸಾರ್ವಜನಿಕ HTTPS ಗುರಿಗೆ SOCKS5 ಪ್ರಾಕ್ಸಿ ಪಟ್ಟಿ ProxyAddr ಮತ್ತು ProxyPort ಗೆ ಅಭ್ಯರ್ಥಿಗಳನ್ನು ನೀಡುತ್ತದೆ. ಈ ತುಣುಕು ಸಾಗಣೆ ಪದರಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ; ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ಗಮ್ಯಸ್ಥಾನ ನಿರೀಕ್ಷಿಸುವ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಕಳುಹಿಸಬೇಕು ಮತ್ತು ಮುಗಿದ ನಂತರ ಸಾಕೆಟ್ ಮುಚ್ಚಬೇಕು.

ಉದ್ದೇಶಿಸಿದ ಪೀರ್ ಹೆಸರನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ

ಪ್ರಾಕ್ಸಿ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮೊದಲ ಸಂಪರ್ಕಕ್ಕೆ ಸೇರಿದೆ. TLS SNI ಮತ್ತು ಹೋಸ್ಟ್‌ಹೆಸರು ಪರಿಶೀಲನೆ example.com ಗೆ ಸಂಬಂಧಿಸಿದೆ. ಆ ಹಂತದಲ್ಲಿ ಪ್ರಾಕ್ಸಿಯ ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ಬಳಸುವುದು ತಪ್ಪು ಗುರುತನ್ನು ಕೇಳಬಹುದು ಅಥವಾ ಪರಿಶೀಲಿಸಬಹುದು.

ಟ್ರಸ್ಟ್-ಸ್ಟೋರ್ ಸಂರಚನೆ ಇನ್ನೊಂದು ಸ್ವತಂತ್ರ ಅಗತ್ಯ. ರೋಗನಿರ್ಣಯದ ಉದಾಹರಣೆಯಿಂದ ನಕಲಿಸಿದ ಎಲ್ಲದನ್ನೂ ನಂಬುವ ಕಾಲ್‌ಬ್ಯಾಕ್ ಬದಲು ಅಪ್ಲಿಕೇಶನ್‌ನ ಉದ್ದೇಶಿತ CA ಸಂರಚನೆಯನ್ನು ಬಳಸಿ.

SOCKS ಹಂತ ವಿಫಲವಾದರೆ TLS ನಿಯತಾಂಕಗಳನ್ನು ಬದಲಿಸುವುದರಿಂದ ಅದು ಸರಿಯಾಗುವುದಿಲ್ಲ. SOCKS ಯಶಸ್ವಿಯಾಗಿ TLS ವಿಫಲವಾದರೆ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಹೋಸ್ಟ್‌ಹೆಸರಿನ ದೋಷವನ್ನು ಸಾಕ್ಷ್ಯವಾಗಿ ಇರಿಸಿಕೊಳ್ಳಿ, ಸಾಮಾನ್ಯ ಪ್ರಾಕ್ಸಿ ವೈಫಲ್ಯವೆಂದು ಪರಿಗಣಿಸಬೇಡಿ.

ಮಾಡ್ಯೂಲ್ ಹೆಸರುಗಳೂ ಮುಖ್ಯ: IO::Socket::Socks ಮತ್ತು IO::Socket::SSL ಬೇರೆ ಬೇರೆ ಕನ್ಸ್ಟ್ರಕ್ಟರ್ ಮತ್ತು ಅಪ್‌ಗ್ರೇಡ್ ವರ್ತನೆ ನೀಡುತ್ತವೆ. ಕೇವಲ ಪ್ರಾಕ್ಸಿ ತಲುಪಿದ ಕಚ್ಚಾ TCP ಸಾಕೆಟ್ ಇನ್ನೂ SOCKS ಗಮ್ಯಸ್ಥಾನ ಮಾತುಕತೆ ಪೂರ್ಣಗೊಳಿಸಿಲ್ಲ.