Връзка само по 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 слушател може да го препрати.

Нищо от това не прави клиента двустеков и нищо от него не е нужно. То прави така, че едно приложение да достигне една услуга през един препращач, което е по-малко твърдение и много по-лесно за проверка.