Политическо маршрутизиране срещу SOCKS: кой слой всъщност проксира трафика

Добавихте политически маршрут, който изпраща трафика на VPN клиент към хост, на който на порт 1080 работи SOCKS слушател. Пакетите пристигат, слушателят не записва нищо и връзката виси. С маршрута няма нищо нередно: следващият хоп избира накъде отива пакетът, а SOCKS е разговор, който клиентът трябва да започне. Сравнете трите архитектури, които хората обикновено имат предвид, когато казват, че прекарват трафик през прокси, и ще стане ясно коя част липсва в настройката ви.

Маршрутизирането, DNAT и SOCKS променят различни неща

Политическият маршрут пренаписва решение от слой 3. Два реда са достатъчни, за да изпратят трафика на един клиент към избран следващ хоп:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

След това ядрото предава пакета на 10.50.0.2, като първоначалната дестинация остава в IP заглавката. Ако 10.50.0.2 е рутер, той препраща пакета. Ако е хост с SOCKS демон на 1080, пакетът не е адресиран до нищо, което може да го приеме, и DNAT към порт 1080 също не помага, защото преобразуваният пакет все още носи оригиналния полезен товар на приложението вместо SOCKS поздрав.

SOCKS5 започва с байт за версия, списък с методи, обмен на автентикация и заявка, която посочва дестинацията. Това са данни на приложението. Нито запис в маршрутизацията, нито цел в netfilter ги генерира, и това е сравнението в един ред: маршрутизирането избира път, а SOCKS иска от сървър да осъществи втора връзка.

Случай първи: приложението само може да говори SOCKS

Когато програмата има настройка за прокси, това е най-краткият път и не изисква промяна в ядрото. Насочете я към слушателя, подайте идентификационни данни, ако сървърът ги поиска, и решете дали имената се решават локално, или се предават на проксито. При curl това са различни флагове и разликата е важна, когато дестинацията се решава само от страната на проксито:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Приложения, които игнорират променливите на средата за прокси или отварят сурови сокети, не могат да бъдат подпомогнати по този начин. Браузърите и повечето HTTP инструменти са наред; игрален клиент, пощенски демон или произволен двоичен файл от доставчик обикновено не са. Границата е за всяко приложение и всеки протокол, затова тази опция е отлична за тестване и слаба като отговор за целия VPN.

Случай втори: адаптер, който преобразува IP потоци в прокси сесии

За програми, които не могат да говорят SOCKS, преобразуването трябва да се случи в нещо, което прекратява IP трафика и отваря прокси сесии от тяхно име. Този компонент притежава тунелен интерфейс, приема потоците, избрани от политическото маршрутизиране, изпълнява SOCKS ръкостискането за всеки от тях и възстановява отговорите. Маршрутът насочва трафика към него; адаптерът е това, което създава сесията.

Прочетете документацията му, преди да му поверите цяла подмрежа. Много адаптери пренасят TCP добре и обработват UDP само чрез UDP асоциация в SOCKS5, и нито един от тях не превръща ICMP в прокси трафик, така че успешният ping не казва нищо за пътя през проксито. DNS е другата капана: ако адаптерът решава имената локално, записите само за вътрешна употреба се решават до грешен отговор или до нищо.

Предотвратяването на цикли е оперативната подробност, която боли. Собствените връзки на адаптера към SOCKS сървъра не бива да се маршрутизират обратно в адаптера, затова трафикът му се нуждае от изключение в правилото или от отделен адрес на източника. Сгрешете ли това, прокси сесията ще се опита да проксира сама себе си.

Случай трети: хостът всъщност е маршрутизиран шлюз

Понякога работещата настройка не съдържа SOCKS изобщо. Отдалеченият хост препраща пакетите или им прави NAT, а правилото, базирано на източника, просто го избира за изход. Този дизайн е законен и обяснява защо копирана конфигурация работи в една мрежа и се проваля в друга: правилото е идентично, липсващата част е услуга за препращане от другата страна.

Трите случая се разделят бързо. Проверете какво всъщност слуша, а после погледнете първите байтове, които достигат до хоста:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Първият байт полезен товар на истински SOCKS клиент е 0x05, версията в поздрава. Ако заснемането показва вместо това оригинални данни на приложението, никой SOCKS демон няма да отговори, защото преговорите така и не са започнали. Ако на 1080 нищо не слуша, хостът е шлюз и въпросът става дали препраща и дали съществува обратен път.

Изберете слоя с четири въпроса

Има ли програмата настройка за прокси? Използвайте я и спрете дотам. Включва ли трафикът UDP или ICMP, които трябва да оцелеят? Само маршрутизиран шлюз или шлюз с NAT пренася ICMP, а UDP се нуждае от SOCKS5 асоциация, която и двете страни поддържат. Трябва ли да бъде покрит всеки процес на машината, включително тези, които не можете да конфигурирате? Тогава ви е нужен адаптер, който притежава интерфейса и прекратява потоците. Можете ли да поемете и неговото маршрутизиране, DNS и изключенията за предотвратяване на цикли? Ако не, обикновеният шлюз ще струва по-малко за експлоатация.

Едно разграничение си струва да се пази точно. Собствената опция socks-proxy на VPN клиента описва как външната тунелна връзка достига до своя сървър и не казва нищо за преобразуването на вътрешните клиентски потоци. Двете постоянно се бъркат в един и същ тикет. Решете каква връзка ви трябва, преди да пипате маршрут.