Палітычная маршрутызацыя супраць 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, які павінен выжыць? ICMP нясе толькі маршрутызаваны шлюз або шлюз NAT, а UDP патрабуе асацыяцыі SOCKS5, якую падтрымліваюць абодва бакі. Ці павінен быць ахоплены кожны працэс на машыне, уключаючы тыя, якія вы не можаце наладзіць? Тады патрэбны адаптар, які валодае інтэрфейсам і завяршае патокі. Ці можаце вы таксама ўзяць на сябе яго маршрутызацыю, DNS і выключэнні для прадухілення пятляў? Калі не, звычайны шлюз абыдзецца танней у эксплуатацыі.

Адно адрозненне варта трымаць дакладна. Уласная налада socks-proxy кліента VPN апісвае, як знешняе тунельнае злучэнне дасягае свайго сервера, і нічога не кажа пра пераўтварэнне ўнутраных патокаў кліента. Гэтыя дзве рэчы пастаянна блытаюць у адной і той жа заяўцы. Вырашыце, якія адносіны вам патрэбны, перш чым кранаць маршрут.