Trafiku i Docker dhe VM pas OpenVPN: rrugëzim apo rinumerim?

Host-i shfleton përmes tunelit dhe kontenieri pranë tij nuk arrin asgjë. Publikimi i një porte nga një kontenier që ekzekuton klientin e vet VPN është më keq: kërkesa mbërrin dhe përgjigjja nuk del kurrë. Të dyja janë vendime rrugëzimi në host, dhe Docker është vetëm lajmëtari.

Tri pyetje përcaktojnë cilin nga dy rastet po shihni, dhe marrin rreth një minutë.

Dy defekte që duken njësoj

I pari është problem i rrugës së kthimit. Porta e publikuar përkthehet në kontenier, kërkesa mbërrin, dhe përgjigjja rrugëzohet përmes rrugës së parazgjedhur të host-it, të cilën klienti OpenVPN e ka drejtuar në tun0. Përgjigjja del nga një adresë që pala e largët nuk e pret, dhe hidhet. I dyti është përplasje prefiksesh: ura e parazgjedhur e Docker zotëron 172.17.0.0/16 dhe një tunel korporativ shtyn të njëjtin interval.

Njëra rregullohet me tabelë rrugëzimi, tjetra duke rinumeruar një urë. Redaktimi para se të dini cila është cila është mënyra për të prishur një kontenier që funksionon.

Vendosni me tri pyetje

Pyetja e parë: a zhduket defekti kur ndaloni VPN-në? Nëse gjithçka funksionon me tunelin të fikur, dyshoni rrugën e kthimit. Pyetja e dytë: a ip route show table all rendit të njëjtin prefiks dy herë, një herë në urë dhe një herë në tun0? Kjo është përplasja. Pyetja e tretë: a është adresa e prekur një kontenier, një mysafir NAT apo një mysafir i urëzuar?

Pyetja e tretë ka rëndësi sepse secili ka një rregullim të saktë të ndryshëm, dhe zbatimi i rregullimit të kontenierit tek një mysafir libvirt harxhon një mbrëmje.

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

Rruga e kthimit: një tabelë për një adresë burimi

Kur trafiku i kontenierit duhet të dalë përmes ndërfaqes fizike ndërsa vetë host-i përdor tunelin, rrugëzimi i bazuar në burim është ndryshimi më i vogël. Shtoni një rregull që përputhet me adresën e kontenierit dhe dërgojeni në një tabelë të dedikuar. Asgjë tjetër në host nuk lëviz.

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

Çdo paketë burimi i së cilës është ajo adresë konsulton së pari tabelën 10, dhe tabela 10 e dërgon atë te porta e urës në vend të tunelit.

Konfirmoni me ip route get 1.1.1.1 from 172.22.0.3. Përgjigjja duhet të përmendë ndërfaqen e urës, jo tun0. Rregullat e shtuara kështu zhduken në rindezje, prandaj vendosini në unit ose në grepën e rrjetit që zotëron kontenierin.

I njëjti model funksionon për një kontenier WireGuard, ku edhe rruga e përgjigjes kërkon një rregull të qartë.

Përplasje prefiksesh: rinumeroni urën

Një tabelë rrugëzimi dërgon një prefiks në një vend. Nëse VPN shtyn 172.17.0.0/16 ndërsa ura e Docker është tashmë atje, fiton metrika më e ulët: Docker instalon rrugën e lidhur me metrikë 0, dhe rruga e shtyrë mbërrin me 50. Atëherë tuneli duket i prishur ndërsa Docker vazhdon të punojë, ose e kundërta, sipas rendit të instalimit. Rinumeroni urën në vend që të luftoni me metrikën.

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

Rindizni Docker pas ndryshimit dhe rikrijoni rrjetet e ndërtuara me gjirin e vjetër. Ndryshimi i metrikës thjesht e zhvendos konfliktin në nisjen tjetër.

VM-të kanë nevojë përsëri për një përgjigje tjetër

Një mysafir libvirt në rrjetin NAT të parazgjedhur trashëgon rrugëzimin e host-it dhe ndalon së arrituri jashtë sapo tuneli i host-it zotëron rrugën e parazgjedhur. Kalimi i mysafirit në një pajisje të urëzuar ose macvtap i jep atij rrugën e vet në rrjetin fizik. Në virt-manager shtoni hardware, zgjidhni Network, vendosni burimin në pajisjen host macvtap, mbani virtio si model, pastaj çaktivizoni ndërfaqen e vjetër NAT.

Një mysafir macvtap zakonisht nuk mund të arrijë host-in e vet. Kjo është sjellje e pritur dhe jo defekt, dhe i përket shënimit që lini.

Për një mysafir që ka nevojë vetëm për LAN-in e host-it, klienti i furnizorit mund të ketë çelësin që mungon: me Mullvad, mullvad lan set allow rivendos arritshmërinë lokale pa prekur libvirt. Dhe kur një kontenier duhet të jetë i arritshëm vetëm përmes tunelit, lidhni portën e publikuar me adresën e tunelit, -p 10.8.0.5:8080:8080, në vend që ta publikoni në çdo adresë.