Proxy SOCKS5 per a OpenVPN: túnel TCP o fer passar les aplicacions pel proxy?

Les xarxes que només permeten sortir a través d'un proxy són on un perfil que funcionava deixa de funcionar de cop. L'adreça del proxy és la variable menys interessant d'aquesta fallada. Tot ho decideix la forma del trànsit que el proxy retransmetrà, perquè aquests proxies envien un flux de bytes i un túnel UDP no ho és. Això deixa dues arquitectures, i fallen en llocs diferents.

Una restricció decideix el disseny

SOCKS5 sí que especifica un mode d'associació UDP. El suport de proxy del client OpenVPN, però, està construït al voltant de fluxos: socks-proxy està documentat per a perfils TCP, i un proxy HTTP CONNECT no té cap camí per a datagrames. Una línia de documentació resol l'arquitectura abans que toqueu cap fitxer de configuració.

La pregunta, doncs, no és quin proxy triar. És si el túnel es converteix en un flux o es queda com a datagrama i deixa que una altra cosa absorbeixi el proxiejat.

Opció A: convertir el túnel en un flux

Això requereix un servidor amb un oient TCP i un perfil de client que anomeni el proxy. Totes dues peces són necessàries, i el costat del servidor és el que la gent oblida:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Substituïu l'última línia per http-proxy proxy.internal 8080 quan el proxy parla HTTP, i afegiu un fitxer de credencials si en demana. El proxy ha d'acceptar fer CONNECT al vostre port VPN, i el servidor ha de respondre per TCP; un oient només UDP ignora l'intent. Triar 443 és una decisió pràctica, perquè moltes xarxes restrictives ho permeten i poc més.

El cost és TCP sobre TCP. Un segment exterior perdut bloqueja tots els fluxos interiors que comparteixen aquella connexió, així que una recuperació que normalment seria independent es torna compartida. La configuració també triga més, i un camí exterior inestable es converteix en un túnel inestable en lloc d'un de lent.

Opció B: deixar el túnel tranquil

Quan el túnel ha de romandre en UDP, el túnel no és on configureu res. En lloc d'això, el TCP de sortida de les aplicacions es redirigeix a un oient SOCKS local, i les aplicacions mai no saben que existeix un proxy. A Linux això sol ser redsocks més una regla NAT REDIRECT a la taula nat.

Només TCP, un cop més. Un proxy només HTTP com privoxy no pot retransmetre protocols arbitraris, i aquest disseny tampoc no afegeix suport de datagrames per a les aplicacions.

Dir a cada aplicació que hi ha un proxy directament sol ser millor quan el programari ho admet. És més fàcil d'auditar, i falla en un lloc que realment podeu veure.

On falla cada opció

L'opció A falla quan al servidor li falta un oient TCP, quan el proxy rebutja l'objectiu CONNECT o quan el flux exterior està limitat per sota del que el túnel necessita. Les dues primeres deixen una entrada al registre del proxy; la tercera deixa una connexió que s'estableix i després sembla incorrecta. Llegiu aquest registre abans d'editar el perfil, perquè separa un problema de permisos d'un de capacitat. Un CONNECT complet mou la investigació dins del túnel.

L'opció B falla per a qualsevol cosa que necessiti datagrames, per als protocols que el proxy no entén, i en silenci en amfitrions on la regla de redirecció existeix però l'encaminament envia el trànsit més enllà.

Cap de les dues opcions no canvia el requisit del dispositiu. Els paquets encara necessiten un node TUN o TAP abans que el nucli els encamini, així que el procés encara necessita permís a /dev/net/tun. Un embolcall canvia què passa després que aquell node estigui obert, no si en necessiteu un.

Demostrar quin camí heu construït

Mireu els sòcols, no la icona de la safata. El procés VPN ha de mantenir una connexió establerta amb l'adreça del proxy, i el proxy hauria d'haver registrat l'objectiu que se li va demanar d'assolir:

ss -tnp | grep openvpn

Després aneu a una destinació que només el túnel pugui servir, i a un nom que només el resolutor del túnel pugui respondre. Una connexió proxy completada amb un túnel mort normalment vol dir que l'extrem remot mai no va oferir el transport indicat al vostre perfil.

Anoteu el transport i el proxy que accepta en un lloc durador. Quan el mateix perfil falli en una altra xarxa, aquesta nota descarta o confirma el proxy en segons.