Si të drejtohet vetëm trafiku i kontejnerëve Docker përmes OpenVPN

Lëreni hostin në uplink-un e zakonshëm dhe vendosni një nënrrietë kontejnerësh në tunel: rendi i NAT, rregullat e burimit, iroute i OpenVPN dhe kontrollet MSS.

Paketa e kontejnerit nuk arrin kurrë në tun0 , dhe aftësi shtesë në kontejner nuk do ta ndryshojnë këtë. Midis mysafirit dhe tunelit qëndrojnë dy kërkime rrugë: një brenda hapësirës së emrave të rrjetit të mysafirit, një në host pasi korniza zbret në urë, dhe e dyta konsulton një tabelë tjetër me rregulla përputhjeje të ndryshme. Konfigurimi im referues është një host Linux me një OpenVPN klient që mban 10.8.0.10 në tun0 , një urë Docker në 172.18.0.0/16 , dhe një adresë private që vetëm ana e tunelit mund ta arrijë. Qëllimi mbetet i ngushtë: ajo nënrrietë mysafire del përmes tunelit ndërsa hosti mban uplink-un e zakonshëm.

Të drejtosh klientin VPN brenda kontejnerit është një dizajn tjetër , jo një shkurtore. Atëherë kontejneri zotëron tunelin dhe kredencialet e veta, dhe puna kalon në një Dockerfile në vend që të mbetet në iptables.

Përcjellja zgjedh një rrugë sipas destinacionit, pastaj NAT rishkruan burimin

Kur është vendosur net.ipv4.ip_forward=1 , një paketë e përcjellë drejtohet vetëm sipas destinacionit, në tabelën kryesore. Burimi nuk luan asnjë rol në atë vendim. Vetëm pasi zgjidhet rruga, kerneli ekzekuton POSTROUTING , dhe pikërisht aty qëndron rregulli i vetë Docker: -s 172.18.0.0/16 ! -o br-appnet -j MASQUERADE . Çdo gjë që lë urën drejt një ndërfaqeje tjetër përkthehet, dhe adresa në të cilën kthehet varet nga ndërfaqja ku rruga e dërgoi.

Ky rregull shpjegon shumicën e simptomave për të cilat më pyesin. Nëse tabela kryesore nuk ka rrugë për destinacionin privat, paketa del përmes uplink-ut duke mbajtur adresën fizike të hostit. Ofruesi juaj e hedh destinacionin, ose faqja e largët hedh një burim RFC 1918 që nuk e priste kurrë, dhe kontejneri skadon në kohë ndërsa tuneli mbetet lart dhe i shëndetshëm. Një kapje në tun0 nuk tregon asgjë, dhe ky është shenja. Nëse rruga vërtet tregon drejt tun0 , MASQUERADE rishkruan burimin në 10.8.0.10 , dhe i njëjti kontejner funksionon pa prekur asgjë.

Kërkoni kërkimin që emërton burimin e mysafirit. Pa from dhe iif hosti përgjigjet për soketin e vet dhe raporton një shteg që paketa e përcjellë nuk do ta marrë kurrë:

ip route get 192.168.11.222 from 172.18.0.5 iif br-appnet

Nëse ajo përgjigje emërton uplink-un, tuneli nuk është në pamje dhe asnjë rregullim nga ana e tunelit nuk do të ndihmojë.

Zhvendoseni mysafirin në adresën e vetë tunelit

Ndryshimi më i vogël që funksionon është një rishkrim i qartë i burimit në dalje. Futeni në vend që ta shtoni: Docker tashmë qëndron në krye të POSTROUTING , prandaj një rregull i shtuar me -A vlerësohet pas atij të Docker dhe nuk aktivizohet kurrë.

iptables -t nat -I POSTROUTING 1 -s 172.18.0.0/16 -o tun0 -j SNAT --to-source 10.8.0.10

Dy kushte vendosin nëse kjo do të qëndrojë. Adresa duhet të jetë ajo që klienti me të vërtetë mban, prandaj fiksojeni me një hyrje për klient që përmban ifconfig-push 10.8.0.10 255.255.255.0 ; një rregull që emërton një adresë që nuk është caktuar kurrë prodhon hedhje të heshtura, jo gabim. Dhe ana e largët duhet ta pranojë atë burim dhe t'i drejtojë përgjigjet mbrapsht, prandaj lista e lejuar atje emërton adresën e tunelit dhe jo nënrrietën mysafire. Kur adresa e klientit është dinamike, -j MASQUERADE me -o tun0 ndjek atë që ka ndërfaqja, me koston e një politike të largët kundër së cilës nuk mund të shkruani vlerë fikse.

Filtrimi është gjysma tjetër. Docker vendos politikën FORWARD në drop dhe pastron zinxhirët që zotëron në çdo rinisje të demonit, prandaj vendosni politikën lokale në DOCKER-USER , e cila mbijeton:

iptables -I DOCKER-USER -i br-appnet -o tun0 -j ACCEPT
iptables -I DOCKER-USER -i tun0 -o br-appnet -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Rregulli i kthimit ka rëndësi: një përgjigje që arrin në tun0 për një lidhje të hapur nga ura nuk pranohet vetëm sepse drejtimi i daljes ishte.

Mbajeni hostin direkt me një rregull burimi

Kur e gjithë ura duhet të përdorë tunelin por asgjë tjetër në host nuk duhet, kaloni NAT dhe jepini atij burimi tabelën e vet. Adresat mysafire atëherë mbeten të dukshme nga fillimi në fund.

echo "200 vpnbox" >> /etc/iproute2/rt_tables
ip rule add from 172.18.0.0/16 lookup vpnbox pref 1000
ip route add default dev tun0 table vpnbox

Rregullat konsultohen para tabelës kryesore, dhe from përputhet me burimin. Paketat e jashtme të vetë tunelit mbajnë burimin fizik të hostit, prandaj nuk përputhen kurrë me from 172.18.0.0/16 , dhe tuneli nuk mund të drejtojë veten mbrapsht në vetvete. Pikërisht ky vetëpërjashtim e bën konfigurimin të qëndrueshëm.

Rruga e kthimit tani ka nevojë për ndihmë. Ana e largët sheh një 172.18.0.x të papërkthyer dhe nuk ka arsye të dijë ku jeton. Në server, një skedar për klient ka nevojë për iroute 172.18.0.0 255.255.0.0 që tabela e brendshme e serverit ta japë atë prefiks këtij klienti, dhe për një route 172.18.0.0 255.255.0.0 të shtyrë që klientët e tjerë ta dinë se ekziston.

Dy kontrolle përpara se t'i besoni. Ekzekutoni ip route show default : me redirect-gateway def1 tabela mban 0.0.0.0/1 dhe 128.0.0.0/1 përmes tun0 , dhe hosti nuk është aspak direkt, sepse ato gjysmë-të parazgjedhura fitojnë pa zëvendësuar default . Rregullat e shtuara me ip rule add gjithashtu zhduken në rinisje, prandaj mbajini në një skript up.

Madhësia e paketës është dështimi i dytë që hasni

Një ndërfaqe ure në 1500 bajt i jep tunelit më shumë sesa mund të mbajë pasi shtohen kokat UDP dhe IP të jashtme. Shkëmbimet e vogla kalojnë, prandaj DNS zgjidhet dhe shtrëngimi i duarve TLS përfundon, pastaj një ngarkim më i madh ngec pa asnjë gabim kudo. Dërguesi vazhdon të përsëritë të njëjtën madhësi segmenti sepse mesazhi ICMP për nevojën e fragmentimit, që do t'i thoshte të zvogëlohej, nuk arrin kurrë.

Rregullojeni në ndërfaqe, në MSS ose në të dyja. Shtrëngimi nuk kërkon bashkëpunim nga mysafiri:

ip link set dev tun0 mtu 1400
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Shtrëngimi rishkruan vetëm TCP. UDP, përfshirë QUIC, ka nevojë në vend të kësaj për një ndërfaqe mysafire më të ulët, me --opt com.docker.network.driver.mtu=1400 në krijimin e rrjetit ose çelësin compose përkatës.

DNS dhe kontrollet që ia vlen të përsëriten

Zgjidhja e emrave ndjek të njëjtën rrugë. Zgjidhësi i integruar i Docker në 127.0.0.11 përcjell te serverat e konfiguruar të hostit, prandaj kontejneri trashëgon atë që përdor hosti. Kur zona private përgjigjet vetëm nga një zgjidhës i arritshëm përmes tunelit, drejtojeni mysafirin te ajo adresë, dhe provojeni me getent hosts brenda kontejnerit dhe jo në host.

  • Ekzekutoni kërkesën që dështon brenda mysafirit; një provë në anën e hostit përdor një adresë tjetër burimi dhe e fsheh problemin.
  • Lexoni numëruesit në rregullat NAT dhe të filtrimit që shtuat. Një rregull pa asnjë përputhje është gabim drejtimi, jo gabim politike.
  • Konfirmoni se adresa e tunelit në rregullin tuaj SNAT është ajo që klienti me të vërtetë mban.
  • Uluni MTU-në e mysafirit ose shtrëngoni MSS para se të fajësoni serverin për një ngecje.

Kaloni nëpër atë listë dhe ndaloni në dështimin e parë. Ai shtresë është ajo që duhet rregulluar; çdo gjë e shtuar më poshtë fsheh vetëm kufirin që thyhet.

Artikuj të ngjashëm