Trànsit de Docker i MVs darrere d'OpenVPN: encaminar o renumerar?

L'amfitrió navega pel túnel i el contenidor del costat no arriba enlloc. Publicar un port des d'un contenidor que executa el seu propi client VPN és pitjor: la sol·licitud arriba i la resposta no surt mai. Totes dues són decisions d'encaminament a l'amfitrió, i Docker només és el missatger.

Tres preguntes decideixen quin dels dos casos tens davant, i triguen aproximadament un minut.

Dos errors que es presenten de la mateixa manera

El primer és un problema del camí de tornada. El port publicat es tradueix cap al contenidor, la sol·licitud arriba i la resposta s'encamina per la ruta per defecte de l'amfitrió, que el client OpenVPN ha apuntat a tun0. La resposta surt d'una adreça que el parell remot no espera i es descarta. El segon és una col·lisió de prefixos: el pont per defecte de Docker posseeix 172.17.0.0/16 i un túnel corporatiu empeny el mateix rang.

Un es corregeix amb una taula d'encaminament, l'altre renumerant un pont. Editar abans de saber quin és quin és com es trenca un contenidor que funcionava.

Decideix-ho amb tres preguntes

Pregunta u: desapareix el error quan atures la VPN? Si tot funciona amb el túnel aturat, sospita del camí de tornada. Pregunta dos: ip route show table all llista el mateix prefix dues vegades, una en un pont i una a tun0? Aquesta és la col·lisió. Pregunta tres: l'adreça afectada és un contenidor, un hoste NAT o un hoste en pont?

La tercera pregunta importa perquè cada cas té una solució correcta diferent, i aplicar la solució del contenidor a un hoste libvirt malbarata un vespre.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Camí de tornada: una taula per a una adreça d'origen

Quan el trànsit del contenidor ha de sortir per la interfície física mentre l'amfitrió mateix fa servir el túnel, l'encaminament basat en l'origen és el canvi més petit. Afegeix una regla que coincideixi amb l'adreça del contenidor i envia-la a una taula dedicada. Res més de l'amfitrió es mou.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Cada paquet l'origen del qual és aquesta adreça consulta primer la taula 10, i la taula 10 l'envia a la porta d'enllaç del pont en lloc del túnel.

Confirma-ho amb ip route get 1.1.1.1 from 172.22.0.3. La resposta ha de nomenar la interfície del pont, no tun0. Les regles afegides així desapareixen en reiniciar, així que posa-les a la unitat o al ganxo de xarxa que posseeix el contenidor.

El mateix patró funciona per a un contenidor WireGuard, on el camí de resposta també necessita una regla explícita.

Col·lisió de prefixos: renumera el pont

Una taula d'encaminament envia un prefix a un sol lloc. Si la VPN empeny 172.17.0.0/16 mentre el pont de Docker ja hi és, guanya la mètrica més baixa: Docker instal·la la seva ruta connectada amb mètrica 0 i la ruta empenyuda arriba amb 50. Llavors el túnel sembla trencat mentre Docker continua funcionant, o al revés, segons l'ordre d'instal·lació. Renumera el pont en lloc de barallar-te amb la mètrica.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

Reinicia Docker després del canvi i torna a crear les xarxes construïdes amb el pool antic. Canviar la mètrica només trasllada el conflicte al proper arrencada.

Les MVs necessiten encara una altra resposta

Un hoste libvirt a la xarxa NAT per defecte hereta l'encaminament de l'amfitrió i deixa d'arribar a l'exterior quan el túnel de l'amfitrió posseeix la ruta per defecte. Canviar l'hoste a un dispositiu en pont o macvtap li dona el seu propi camí a la xarxa física. A virt-manager, afegeix maquinari, tria Network, posa l'origen al dispositiu d'amfitrió macvtap, mantén virtio com a model i després desactiva la interfície NAT antiga.

Un hoste macvtap normalment no pot arribar al seu propi amfitrió. És un comportament esperat i no una fallada, i pertoca a la nota que deixes.

Per a un hoste que només necessita la LAN de l'amfitrió, el client del proveïdor pot tenir l'interruptor que falta: amb Mullvad, mullvad lan set allow restaura l'abast local sense tocar libvirt. I quan un contenidor ha de ser accessible només pel túnel, lliga el port publicat a l'adreça del túnel, -p 10.8.0.5:8080:8080, en lloc de publicar-lo a cada adreça.