Encaminar un compte Linux a través d’OpenVPN amb una regla UID

L’encaminament per compte encaixa quan cada socket IPv4 propietat d’un usuari Linux ha de sortir per un túnel existent, i no encaixa quan necessiteu aïllament a nivell de programa. Selecciona per UID, així que tot el que s’executa amb aquest compte queda dins l’abast, inclosa la feina per lots que heu oblidat. Resoleu aquesta qüestió abans de tocar una sola ip rule.

L’exemple següent assumeix un compte de navegador dedicat a l’UID 1500, un dispositiu de túnel tun-office amb adreça local 10.80.0.11, i una VPN que permet les destinacions en qüestió. El dimoni mateix s’executa fora d’aquest UID.

Tres condicions que trien el mecanisme

Trieu una regla UID quan la identitat que fa la feina és el compte, quan moure tot el seu trànsit és acceptable i quan un namespace seria més feixuc del que la tasca mereix. Trieu un namespace de xarxa quan la càrrega de treball necessita les seves pròpies interfícies, resolutor i taula d’encaminament. Trieu un proxy o una vinculació per procés quan exactament una aplicació ha de moure’s mentre la resta de la sessió es queda al camí local. Posar aquestes tres coses per escrit evita una regla que cobreix en silenci més del previst.

L’error a evitar és suposar que un llançador defineix el propietari. Un navegador que rep una URL de la sessió d’un altre usuari no ha creat sockets sota l’UID 1500, i cap regla mourà el trànsit que genera.

La taula, la regla i el guardià

Després de comprovar les regles existents i triar números de taula i prioritat no usats, la disposició és curta: una ruta per defecte en una taula dedicada que porta l’adreça d’origen del túnel, una regla que envia les consultes del compte a aquesta taula, i una regla terminant que bloqueja el retorn. Escrit, això és un reemplaçament de ruta idempotent, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, seguit de ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

El guardià és ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, i importa més del que suggereix la seva longitud. Sense ell, una ruta absent a la taula 51820 cau cap a l’enllaç ascendent ordinari i el compte filtra en silenci trànsit que la política havia de capturar. Amb ell, la mateixa fallada es converteix en un temps d’espera, és a dir, bloqueig en lloc de retorn.

Manteniu la regla normal d’adreça local per davant d’aquestes, i decidiu conscientment si les excepcions de LAN o de gestió van abans de la taula seleccionada. Una ruta per defecte trobada allà no consulta després main per una ruta LAN més específica, cosa que sorprèn qui espera que la coincidència de prefix més llarg s’apliqui entre taules. Escriviu la llista d’excepcions prevista a la nota de canvi mentre el raonament encara és fresc.

Què deixa fora l’encaminament per UID: DNS

El dimoni resolutor obre els seus sockets ascendents sota el seu propi UID, així que seleccionar 1500 no mou aquestes consultes a la taula 51820. La integració de DNS és una decisió separada: apunteu el compte a un resolutor abastable pel túnel, o accepteu que la resolució de noms segueix el camí de l’amfitrió mentre el trànsit no ho fa.

Una consulta per loopback a un stub local no és prova que la consulta ascendent utilitzés la ruta del navegador, ni ho és una càrrega de pàgina amb èxit des de la memòria cau.

IPv6 necessita la seva pròpia frase al disseny

Les regles anteriors només cobreixen IPv4. Si el requisit és un túnel IPv4 sense IPv6 directe des d’aquest compte, afegiu una regla terminant revisada com ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, i després comproveu les regles IPv6 anteriors més les excepcions de loopback que vulgueu mantenir.

Bloquejar IPv6 directe no és tunelització de doble pila; és una frontera. Anomenar-ho tunelització confondrà la següent persona que llegeixi la política, i la confusió sortirà com un tiquet de suport sobre un lloc IPv6 trencat.

Verifiqueu amb el compte real, i després assumiu el cicle de vida

Compareu consultes: ip -4 route get 198.51.100.25 uid 1500 contra la mateixa destinació amb un UID ordinari. Després feu una petició permesa sota el compte dedicat i comproveu l’adreça d’origen que veu l’extrem remot. Una adreça d’origen preferida no és source NAT, i no passarà per sobre d’una aplicació que enllaça una altra cosa. Si totes dues consultes retornen el mateix camí, la regla no fa el que penseu.

Manteniu la taula, les regles i la vida de la ruta del túnel sota un sol propietari, proveu una reconnexió i una pèrdua de túnel, i en retirar la política elimineu només les seves entrades exactes. Un namespace encara és disponible si interfícies separades i estat separat són el que realment necessiteu.