Политичко насочување наспроти 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 клиентот опишува како надворешната тунелска врска стигнува до својот сервер, и не кажува ништо за претворањето на внатрешните текови на клиентот. Двете постојано се мешаат во истиот тикет. Одлучете каков однос ви треба пред да допрете рута.