Docker- og VM-umferð bak við OpenVPN: beina eða endurnúmera?

Vélin vafrar í gegnum gönguna og gámurinn við hliðina nær engu. Að birta port úr gámi sem keyrir sinn eigin VPN-biðlara er verra: beiðnin kemur og svarið fer aldrei út. Bæði eru beiningarákvarðanir á vélinni, og Docker er bara boðberinn.

Þrjár spurningar ákvarða hvorra tilvikanna þú ert að horfa á, og þær taka um það bil eina mínútu.

Tvö bilunartilvik sem líta eins út

Það fyrra er vandamál með afturleiðina. Birt port er þýtt inn í gáminn, beiðnin kemur og svarinu er beint um sjálfgefna leið vélarinnar, sem OpenVPN biðlarinn hefur beint á tun0. Svarið fer frá netfangi sem fjarskiptaaðilinn í burtu á ekki von á, og því er hent. Það síðara er árekstur forskeyta: sjálfgefna brú Docker á 172.17.0.0/16 og fyrirtækjagöng ýta sama bili.

Önnur er lögð með beiningartöflu, hin með því að endurnúmera brú. Að breyta áður en þú veist hvort er hvort er leiðin til að brjóta gám sem virkar.

Ákveddu með þremur spurningum

Spurning eitt: hverfur bilunin þegar þú stöðvar VPN-ið? Ef allt virkar með gönguna niðri skaltu gruna afturleiðina. Spurning tvö: listar ip route show table all sama forskeytið tvisvar, einu sinni á brú og einu sinni á tun0? Það er áreksturinn. Spurning þrjú: er netfangið sem varð fyrir áhrifum gámur, NAT-gestur eða brúaður gestur?

Þriðja spurningin skiptir máli því hvert hefur aðra rétta viðgerð, og að beita viðgerð gámsins á libvirt-gest eyðir heilu kvöldi.

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

Afturleið: tafla fyrir eitt upprunanetfang

Þegar umferð gámsins þarf að fara út um líkamlega tengið á meðan vélin sjálf notar gönguna, er beining byggð á uppruna minnsta breytingin. Bættu við reglu sem passar við netfang gámsins og sendu hana í sérstaka töflu. Ekkert annað á vélinni hreyfist.

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

Sérhver pakki sem á uppruna sinn í því netfangi skoðar fyrst töflu 10, og tafla 10 sendir hann til hliðs brúarinnar í stað göngunnar.

Staðfestu með ip route get 1.1.1.1 from 172.22.0.3. Svarið verður að nefna tengi brúarinnar, ekki tun0. Reglur sem bætt er við svona hverfa við endurræsingu, svo settu þær í eininguna eða netkrækjuna sem á gáminn.

Sama mynstur virkar fyrir WireGuard-gám, þar sem afturleiðin þarf líka skýra reglu.

Árekstur forskeyta: endurnúmeraðu brúna

Beiningartafla sendir eitt forskeyti á einn stað. Ef VPN-ið ýtir 172.17.0.0/16 á meðan brú Docker er þegar þar, vinnur lægra mæligildið: Docker setur upp tengda leið sína á mæligildi 0, og ýtta leiðin kemur á 50. Þá virðist göngunni bilað á meðan Docker heldur áfram, eða öfugt, eftir uppsetningarröð. Endurnúmeraðu brúna í stað þess að berjast við mæligildið.

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

Endurræstu Docker eftir breytinguna og búðu til netin sem byggð voru með gamla safninu aftur. Að breyta mæligildinu færir átökin bara á næstu ræsingu.

VM þurfa aftur annað svar

libvirt-gestur á sjálfgefna NAT-netinu erfir beiningar vélarinnar og hættir að ná út þegar göng vélarinnar eignast sjálfgefnu leiðina. Að flytja gestinn á brúaða eða macvtap-tæki gefur honum eigin leið á líkamlega netinu. Í virt-manager bætirðu við vélbúnaði, velur Network, setur upprunann á macvtap-vélartækið, heldur virtio sem líkani og afvirkjar svo gamla NAT-tengið.

macvtap-gestur getur yfirleitt ekki náð í sína eigin vél. Þetta er vænt hegðun en ekki bilun, og á heima í athugasemdinni sem þú skilur eftir.

Fyrir gest sem þarf aðeins LAN vélarinnar kann biðlari framleiðandans að hafa vantar rofann: með Mullvad endurheimtir mullvad lan set allow staðbundna aðgengi án þess að snerta libvirt. Og þegar gámur verður aðeins að vera aðgengilegur í gegnum gönguna, bundu birtu portið við netfang göngunnar, -p 10.8.0.5:8080:8080, í stað þess að birta það á hverju netfangi.