Docker- en VM-verkeer agter OpenVPN: roete of hernommer?

Houers en gaste op 'n gasheer met 'n OpenVPN-kliënt verloor óf die terugroete óf bots met die tonnelvoorvoegsel. Drie vrae wys die oplossing.

Die gasheer blaai deur die tonnel en die houer daarnaas bereik niks. Om 'n poort te publiseer vanuit 'n houer wat sy eie VPN-kliënt het, is erger: die versoek kom aan en die antwoord verlaat nooit. Albei is roetebesluite op die gasheer, en Docker is net die boodskapper.

Drie vrae bepaal na watter van die twee jy kyk, en dit neem omtrent 'n minuut.

Twee foute wat dieselfde lyk

Die eerste is 'n probleem met die terugroete. 'n Gepubliseerde poort word na die houer vertaal, die versoek kom aan, en die antwoord word deur die gasheer se verstekroete gestuur, wat die OpenVPN-kliënt na tun0 laat wys het. Die antwoord vertrek vanaf 'n adres wat die eksterne eweknie nie verwag nie, en dit word laat val. Die tweede is 'n voorvoegselbotsing: Docker se verstekbrug besit 172.17.0.0/16 en 'n korporatiewe tonnel stoot dieselfde reeks.

Een word met 'n roetetabel reggemaak, die ander deur 'n brug te hernommer. Om te redigeer voordat jy weet watter een watter is, is hoe 'n werkende houer gebreek word.

Bepaal dit met drie vrae

Vraag een: verdwyn die fout wanneer jy die VPN stop? As alles werk met die tonnel af, vermoed die terugroete. Vraag twee: wys ip route show table all dieselfde voorvoegsel twee keer, een keer op 'n brug en een keer op tun0? Dit is die botsing. Vraag drie: is die geaffekteerde adres 'n houer, 'n NAT-gas of 'n gebrugde gas?

Die derde vraag is belangrik omdat elkeen 'n ander regte oplossing het, en om die houeroplossing op 'n libvirt-gas toe te pas mors 'n aand.

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

Terugroete: 'n tabel vir een bronadres

Wanneer die houer se verkeer deur die fisiese koppelvlak moet uitgaan terwyl die gasheer self die tonnel gebruik, is brongebaseerde roetering die kleinste verandering. Voeg 'n reël by wat by die houer se adres pas en stuur dit na 'n toegewyde tabel. Niks anders op die gasheer skuif nie.

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

Elke pakkie waarvan die bron daardie adres is, raadpleeg eerste tabel 10, en tabel 10 stuur dit na die brug se gateway eerder as na die tonnel.

Bevestig met ip route get 1.1.1.1 from 172.22.0.3. Die antwoord moet die brugkoppelvlak noem, nie tun0 nie. Reëls wat so bygevoeg word, verdwyn by herbegin, so plaas hulle in die eenheid of netwerkhakie wat die houer besit.

Dieselfde patroon werk vir 'n WireGuard-houer, waar die antwoordpad ook 'n eksplisiete reël nodig het.

Voorvoegselbotsing: hernommer die brug

'n Roetetabel stuur een voorvoegsel na een plek. As die VPN 172.17.0.0/16 stoot terwyl Docker se brug al daar is, wen die laer metriek: Docker installeer sy gekoppelde roete op metriek 0, die gestote roete kom aan op 50. Die tonnel lyk dan gebreek terwyl Docker aanhou werk, of andersom, afhangend van die installasievolgorde. Hernommer die brug eerder as om die metriek te beveg.

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

Herbegin Docker ná die verandering en skep netwerke wat met die ou poel gebou is, weer. Om eerder die metriek te verander, verskuif net die konflik na die volgende herbegin.

VM's het weer 'n ander antwoord nodig

'n libvirt-gas op die verstek-NAT-netwerk erf die gasheer se roetering en stop om die buitekant te bereik sodra die gasheertonnel die verstekroete besit. Om die gas na 'n gebrugde of macvtap-toestel oor te skakel, gee hom sy eie pad op die fisiese netwerk. Voeg in virt-manager hardeware by, kies Network, stel die bron op die macvtap-gasheertoestel, hou virtio as die model, en deaktiveer dan die ou NAT-koppelvlak.

'n macvtap-gas kan gewoonlik nie sy eie gasheer bereik nie. Dit is verwagte gedrag eerder as 'n fout, en dit hoort in die nota wat jy agterlaat.

Vir 'n gas wat net die gasheer se LAN nodig het, het die verskaffer se kliënt miskien die ontbrekende skakelaar: met Mullvad herstel mullvad lan set allow plaaslike bereikbaarheid sonder om aan libvirt te raak. En wanneer 'n houer slegs deur die tonnel bereikbaar moet wees, bind die gepubliseerde poort aan die tonneladres, -p 10.8.0.5:8080:8080, in plaas daarvan om op elke adres te publiseer.

Verwante artikels