Рутирање по политици наспрам 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 само кроз SOCKS5 UDP асоцијацију, и ниједан од њих не претвара 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 клијента описује како спољна тунелска веза стиже до свог сервера, и не говори ништа о претварању унутрашњих токова клијента. Њих двоје се стално мешају у истом тикету. Одлучите какав однос вам је потребан пре него што дотакнете руту.