Веза само преко IPv6, услуга на IPv4: нека SOCKS прокси буде мост

Није вам потребна адреса из породице одредишта да бисте га достигли, све док је нешто на путу спремно да проследи. Апликација се повезује са проксијем, а прокси отвара другу везу ка одредишту. То су два сокета са независним породицама адреса, и ништа ни у једном од два протокола не захтева да се поклопе. То је прослеђивање на нивоу апликације, а не изворна IPv4 путања, и та разлика одређује шта ће радити, а шта не. Мешање то двоје је разлог зашто се лаптоп описује као да има IPv4 повезаност када је све што има прокси.

Два сокета, две породице адреса

SOCKS5 захтев именује одредиште у једном од три облика: буквална v4 адреса, буквална v6 адреса или име које прокси треба да реши. Захтев описује где прокси треба да се повеже, а не како изгледа веза клијента са проксијем.

Читајте ове типове адреса као три независна избора у једној поруци. Прокси доступан преко IPv6 може да отвори сокет одредишта IPv4 када има исправан IPv4 излаз и када његова политика дозвољава захтев. Спецификација SOCKS5 дефинише их без икаквог позивања на транспорт клијента.

Контролисани пример са SSH

Узмите SSH домаћин који вам је дозвољено да користите, који одговара на IPv6 и сам може да достигне HTTPS услугу која постоји само на v4. Динамичко прослеђивање OpenSSH поставља локални SOCKS слушалац на вашу машину док сесија пријављивања иде преко v6.

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

Домаћин и налог горе су примери, а loopback повезивање држи слушалац на овом рачунару. Не замењујте га повезивањем на све адресе да би канцеларија могла да дели неаутентификовани прокси. 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 слушалац може да га проследи.

Ништа од овога не чини клијента двоструким стеком и ништа од тога није потребно. То чини да једна апликација достигне једну услугу кроз једног прослеђивача, што је мања тврдња и много лакше проверљиво.