Оған жету үшін сізге межелік мекенжай тобының мекенжайы қажет емес, жолдағы бір нәрсе қайта жіберуге дайын болса жеткілікті. Қолданба проксиге қосылады, ал прокси межелікке екінші қосылым ашады. Бұл мекенжай топтары тәуелсіз екі сокет, және екі протоколдың ешқайсысы олардың сәйкесуін талап етпейді. Бұл қолданба деңгейіндегі қайта жіберу, табиғи IPv4 жолы емес, және дәл осы айырмашылық не істейтінін және не істемейтінін анықтайды. Екеуін шатастыру — ноутбуктің тек проксиі болса да, IPv4 байланысы бар деп сипатталуының себебі.

Екі сокет, екі мекенжай тобы

SOCKS5 сұранысы межелікті үш пішіннің бірімен атайды: сөзбе-сөз v4 мекенжайы, сөзбе-сөз v6 мекенжайы немесе прокси шешетін атау. Сұраныс проксидің қайда қосылуы керектігін сипаттайды, клиенттен проксиге дейінгі қосылымның қалай көрінетінін емес.

Бұл мекенжай түрлерін бір хабарламадағы үш тәуелсіз таңдау ретінде оқыңыз. IPv6 арқылы қолжетімді прокси жұмыс істейтін IPv4 шығысы болса және оның саясаты сұранысқа рұқсат етсе, IPv4 межелік сокетін аша алады. SOCKS5 спецификациясы оларды клиенттің тасымалына мүлдем сілтеме жасамай анықтайды.

Бақыланатын SSH мысалы

Пайдалануға рұқсатыңыз бар SSH хостты алыңыз, ол IPv6 арқылы жауап береді және өзі тек v4-те бар HTTPS қызметіне жете алады. OpenSSH динамикалық бағыттауы кіру сессиясы v6 арқылы жүріп жатқанда машинаңызға жергілікті SOCKS тыңдаушысын қояды.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

Жоғарыдағы хост пен тіркелгі мысалдар, ал loopback байланыстыруы тыңдаушыны осы компьютерде ұстайды. Кеңсе растаусыз проксиді бөлісуі үшін оны wildcard байланыстырумен алмастырмаңыз. ExitOnForwardFailure=yes сәтсіз бағыттау сессияны аяқтауы үшін бар, артқы жоспарда үнсіз пәрмен қалдыру үшін емес.

Сессия жұмыс істеп тұрғанда сұраныс осылай көрінеді:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

Loopback қосылымы IPv4 интернет жолы емес. Машинаңыздан шығатын нәрсе — v6 арқылы кіру сессиясы, ал межелік сокетін алыс жақ ашады. socks5h пішіні атауларды шешуді де сол жаққа тапсырады, бұл клиенттің өз IPv4 шешуші жолы болмағанда маңызды.

Межелік шын мәнінде нені көреді

Межелік қайта жіберушінің шығыс мекенжайын көреді. Онда ноутбукіңізге тиесілі ешбір мекенжай көрінбейді. Сол қызметтегі көзге рұқсат етілген тізім қайта жіберушіні атауы керек. Оның журналдары да трафикті қайта жіберушіге жатқызады. Мұны аудиттен бұрын өзгерістер жазбасына жазыңыз, өйткені клиент мекенжайларының айналасында құрылған рұқсат тізімі бірінші сұраныста-ақ сәтсіз болады.

Қайта жіберуші — әңгіменің екі жартысы көрінетін орын да, бұл диагностика кезінде пайдалы қасиет және қайта жіберуші саясатсыз бөлісілсе, салмақ.

Бұл DNS64 немесе NAT64 емес

DNS64 v4 межеліктерін алмастыратын синтезделген жазбалармен жауап береді, ал NAT64 пакеттерді конфигурацияланған жол бойымен қайта жазады. Екеуі де мұнда болып жатқанды сипаттамайды: бір тасымал әңгімесі бітіп, екіншісі басталады және ешбір синтезделген мекенжай нәтижені түсіндірмейді. Сондықтан сәтті сұраныс провайдеріңіздің қандай аударма қызметтерін жүргізетіні туралы ештеңе айтпайды, ал прокси өз шығысында қарапайым NAT іске қосуы мүмкін.

Екі механизм де бір желіде болуы мүмкін, сондықтан ең жақын естілетінді емес, шынымен тексергеніңізді сипаттаңыз.

Уәде бермес бұрын ауқымды біліңіз

OpenSSH динамикалық бағыттауы TCP қосылымдарын тасымалдайды, ерікті IP трафигін емес, сондықтан UDP, ICMP және проксиді елемейтін кез келген протокол басқа қолдаулы жобаны қажет етеді. SSH хост кілтін тексеруді, сервердің бағыттау шектеулерін және HTTPS сертификатын валидациялауды сақтаңыз, өйткені прокси — қосымша сенімді қатысушы, жеке басты тексеруді әлсіретудің себебі емес. Мақсат VPN-нің сыртқы тасымалын прокси арқылы өткізу болса, кез келген SOCKS тыңдаушысы оны қайта жібере алады деп болжаудың орнына екі ұшы да бұл тасымалды қолдайтынын тексеріңіз.

Бұлардың ешқайсысы клиентті қос стекті етпейді және оның қажеті жоқ. Бұл бір қолданбаның бір қайта жіберуші арқылы бір қызметке жетуін қамтамасыз етеді, бұл кішірек мәлімдеме және тексеруге әлдеқайда жеңіл.

Қатысты мақалалар