Encaminament per política contra SOCKS: quina capa fa realment de proxy

Heu afegit una ruta per política que envia el trànsit d’un client VPN a un amfitrió que executa un oient SOCKS al port 1080. Els paquets arriben, l’oient no registra res i la connexió es penja. La ruta no té cap problema: el següent salt tria on va un paquet, i SOCKS és una conversa que el client ha d’iniciar. Compareu les tres arquitectures que la gent sol voler dir quan envia trànsit a través d’un proxy i quedarà clar quina peça falta a la vostra configuració.

L’encaminament, el DNAT i SOCKS canvien coses diferents

Una ruta per política reescriu una decisió de capa 3. Dues línies són suficients per enviar el trànsit d’un client a un següent salt triat:

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

Després d’això, el nucli lliura el paquet a 10.50.0.2 amb la destinació original encara a la capçalera IP. Si 10.50.0.2 és un encaminador, reenvia el paquet. Si és un amfitrió amb un dimoni SOCKS al 1080, el paquet no està adreçat a res que el pugui acceptar, i el DNAT cap al port 1080 tampoc no ajuda, perquè un paquet traduït encara porta la càrrega original de l’aplicació en lloc d’una salutació SOCKS.

SOCKS5 comença amb un byte de versió, una llista de mètodes, un intercanvi d’autenticació i una petició que nomena la destinació. Això són dades d’aplicació. Cap entrada d’encaminament ni cap objectiu de netfilter les genera, i aquesta és la comparació en una línia: l’encaminament tria un camí, SOCKS demana a un servidor que faci una segona connexió.

Cas primer: l’aplicació pot parlar SOCKS ella mateixa

Quan el programa té una configuració de proxy, aquest és el camí més curt i no necessita cap canvi al nucli. Apunteu-lo a l’oient, proporcioneu credencials si el servidor les demana i decidiu si els noms es resolen localment o es passen al proxy. Amb curl són indicadors diferents, i la diferència importa quan la destinació només es resol des del costat del proxy:

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

Les aplicacions que ignoren les variables d’entorn de proxy, o que obren sockets en brut, no es poden ajudar així. Els navegadors i la majoria d’eines HTTP van bé; un client de jocs, un dimoni de correu o un binari arbitrari d’un proveïdor normalment no. La frontera és per aplicació i per protocol, per això aquesta opció és excel·lent per provar i feble com a resposta per a tot el VPN.

Cas segon: un adaptador que converteix fluxos IP en sessions de proxy

Per als programes que no poden parlar SOCKS, la conversió ha de passar en alguna cosa que acabi el trànsit IP i obri sessions de proxy en el seu nom. Aquest component posseeix una interfície de túnel, accepta els fluxos que ha triat l’encaminament per política, fa l’apretada de mans SOCKS per a cadascun i reconstrueix les respostes. La ruta hi adreça el trànsit; l’adaptador és el que crea la sessió.

Llegiu-ne la documentació abans de confiar-hi una subxarxa sencera. Molts adaptadors porten bé TCP i només tracten UDP mitjançant una associació UDP de SOCKS5, i cap d’ells converteix ICMP en trànsit de proxy, així que un ping correcte no diu res sobre el camí del proxy. El DNS és l’altra trampa: si l’adaptador resol els noms localment, els registres només interns es resolen a una resposta equivocada, o a res de res.

La prevenció de bucles és el detall operatiu que mossega. Les connexions pròpies de l’adaptador al servidor SOCKS no s’han d’encaminar de tornada a l’adaptador, així que el seu trànsit necessita una excepció a la regla o una adreça d’origen dedicada. Si ho feu malament, la sessió de proxy intentarà fer de proxy de si mateixa.

Cas tercer: l’amfitrió és en realitat una passarel·la encaminada

De vegades la configuració que funciona no conté cap SOCKS. L’amfitrió remot reenvia els paquets o hi aplica NAT, i la regla basada en l’origen simplement el tria com a sortida. Aquest disseny és legítim i explica per què una configuració copiada funciona en una xarxa i falla en una altra: la regla és idèntica, la peça que falta és un servei de reenviament a l’altre costat.

Els tres casos se separen de seguida. Comproveu què està escoltant realment i després mireu els primers bytes que arriben a l’amfitrió:

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

El primer byte de càrrega d’un client SOCKS real és 0x05, la versió de la salutació. Si la captura mostra dades originals de l’aplicació en lloc d’això, cap dimoni SOCKS respondrà, perquè la negociació no va començar mai. Si no hi ha res escoltant al 1080, l’amfitrió és una passarel·la i la pregunta passa a ser si reenvia i si existeix un camí de tornada.

Trieu la capa amb quatre preguntes

El programa té una configuració de proxy? Feu-la servir i atureu-vos aquí. El trànsit inclou UDP o ICMP que han de sobreviure? Només una passarel·la encaminada o amb NAT porta ICMP, i l’UDP necessita una associació SOCKS5 que tots dos extrems admetin. Cal cobrir tots els processos de la màquina, inclosos els que no podeu configurar? Llavors necessiteu un adaptador que posseeixi la interfície i acabi els fluxos. Podeu assumir també l’encaminament, el DNS i les excepcions de prevenció de bucles? Si no, la passarel·la simple costarà menys d’explotar.

Una distinció val la pena mantenir clara. L’opció socks-proxy pròpia d’un client VPN descriu com la connexió del túnel exterior arriba al seu servidor i no diu res sobre la conversió dels fluxos interns del client. Les dues es confonen constantment en el mateix tiquet. Decidiu quina relació necessiteu abans de tocar una ruta.