Злучэнне толькі па 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-слухач можа яго перадаць.

Нішто з гэтага не робіць кліента двухстэкавым, ды гэта і не патрэбна. Гэта дазваляе аднаму прыкладанню дасягнуць адной службы праз аднаго пасярэдніка, што з’яўляецца меншым сцвярджэннем і значна прасцейшым для праверкі.