Tráfico de Docker e VM detrás de OpenVPN: encamiñar ou renumerar?

Os contedores e os convidados dunha máquina con cliente OpenVPN ou perden o camiño de volta ou chocan co prefixo do túnel. Tres preguntas escollen a solución.

A máquina navega polo túnel e o contedor de ao lado non chega a nada. Publicar un porto desde un contedor que executa o seu propio cliente VPN é peor: a petición chega e a resposta nunca sae. Ambas son decisións de encamiñamento na máquina, e Docker só é o mensaxeiro.

Tres preguntas deciden cal dos dous casos tes diante, e tardan arredor dun minuto.

Dous fallos que se presentan igual

O primeiro é un problema do camiño de volta. O porto publicado tradúcese cara ao contedor, a petición chega e a resposta encamíñase pola ruta predeterminada da máquina, que o cliente OpenVPN apuntou a tun0. A resposta sae dun enderezo que o par remoto non espera e descártase. O segundo é unha colisión de prefixos: a ponte predeterminada de Docker posúe 172.17.0.0/16 e un túnel corporativo empuxa o mesmo rango.

Un corríxese cunha táboa de encamiñamento e o outro renumerando unha ponte. Editar antes de saber cal é cal é a forma de romper un contedor que funcionaba.

Decídeo con tres preguntas

Pregunta unha: desaparece o fallo cando detés a VPN? Se todo funciona co túnel baixo, sospeita do camiño de volta. Pregunta dúas: ip route show table all lista o mesmo prefixo dúas veces, unha nunha ponte e outra en tun0? Esa é a colisión. Pregunta tres: o enderezo afectado é un contedor, un convidado NAT ou un convidado en ponte?

A terceira pregunta importa porque cada un ten unha solución correcta distinta, e aplicar a solución do contedor a un convidado libvirt desperdicia unha noite.

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

Camiño de volta: unha táboa para un enderezo de orixe

Cando o tráfico do contedor debe saír pola interface física mentres a máquina usa o túnel, o encamiñamento baseado na orixe é o cambio máis pequeno. Engade unha regra que coincida co enderezo do contedor e énviaa a unha táboa dedicada. Nada máis da máquina se move.

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

Cada paquete cuxa orixe é ese enderezo consulta primeiro a táboa 10, e a táboa 10 envíao á pasarela da ponte en lugar do túnel.

Confírmao con ip route get 1.1.1.1 from 172.22.0.3. A resposta debe nomear a interface da ponte, non tun0. As regras engadidas así desaparecen ao reiniciar, así que pona na unidade ou no gancho de rede que posúe o contedor.

O mesmo patrón funciona para un contedor WireGuard, onde o camiño de resposta tamén precisa unha regra explícita.

Colisión de prefixos: renumera a ponte

Unha táboa de encamiñamento envía un prefixo a un só lugar. Se a VPN empuxa 172.17.0.0/16 mentres a ponte de Docker xa está alí, gaña a métrica máis baixa: Docker instala a súa ruta conectada con métrica 0 e a ruta empuxada chega con 50. Entón o túnel parece roto mentres Docker segue funcionando, ou ao revés, segundo a orde de instalación. Renumera a ponte en lugar de loitar coa métrica.

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

Reinicia Docker tras o cambio e volve crear as redes construídas co grupo antigo. Cambiar a métrica só traslada o conflito ao seguinte arrinque.

As VM necesitan outra resposta distinta

Un convidado libvirt na rede NAT predeterminada herda o encamiñamento da máquina e deixa de alcanzar o exterior cando o túnel da máquina posúe a ruta predeterminada. Cambiar o convidado a un dispositivo en ponte ou macvtap dálle o seu propio camiño na rede física. En virt-manager, engade hardware, escolle Network, pon a orixe no dispositivo de máquina macvtap, mantén virtio como modelo e despois desactiva a interface NAT antiga.

Un convidado macvtap normalmente non pode alcanzar a súa propia máquina. É un comportamento esperado e non un fallo, e pertence á nota que deixas.

Para un convidado que só precisa a LAN da máquina, o cliente do provedor pode ter o interruptor que falta: con Mullvad, mullvad lan set allow restaura o alcance local sen tocar libvirt. E cando un contedor debe ser accesible só polo túnel, ata o porto publicado ao enderezo do túnel, -p 10.8.0.5:8080:8080, en lugar de publicalo en cada enderezo.

Artigos relacionados