Dockeri konteinerite liiklus möödub hosti VPN-ist: kuidas seda kontrollida
Hosti VPN katab ainult hosti nimeruumi. Nende kontrollidega saate teada, kas sillal olevate konteinerite liiklus siseneb tunnelisse või väljub otse.
Hosti brauser näitab VPN-i väljumisaadressi, konteiner teatab teie koduse ühenduse ja keegi nimetab seda lekkimiseks. Midagi ei lekinud. Hosti tunnel on hulk liideseid, marsruute ja reegleid, mis kuuluvad hosti võrgu nimeruumi, ja sillal olev konteiner on teine nimeruum oma vaikemarsruudiga. Olen istunud Compose'i virna otsas, kus VPN-klient oli olnud ühendatud nädalaid ja mitte ükski konteineri pakett ei olnud sinna kunagi sisenenud.
Kontrollige nimeruumi enne salve ikooni
Nimeruumid on kogu argument. Kui Docker käivitab konteineri sildvõrgus, loob see võrgu nimeruumi, kinnitab selle sisse veth-paari ühe otsa ja annab sellele nimeruumile aadressi ja vaikemarsruudi. Tunneli liides, kuidas iganes seda kutsutakse, elab hosti nimeruumis. Konteineri sees olev liiklus ei näe seda ja ükski kliendi seade ei muuda seda väljastpoolt.
Kaks toetatud käiku viivad teid isolatsioonist välja. --network host paigutab konteineri hosti nimeruumi, nii et see pärineb hosti marsruudid ja seega ka tunneli. --network container:vpn jagab teise konteineri nimeruumi ja nii saadavad enamik sidecar-arhitektuure töökoormuse läbi VPN-konteineri. Mõlemad on selgesõnalised valikud; tavaliselt on ainult üks neist see, mida juurutaja silmas pidas.
Hosti režiim ei ole tasuta uuendus. Konteiner kaotab oma aadressi, pordi avaldamine lakkab kehtimast ja protsess, millel on seal NET_ADMIN, võib hosti marsruutimise ümber kirjutada. Sellega nõustumine võib olla õige otsus. Eeldada, et see on juba sees, on viis, kuidas inimesed veedavad õhtu siludes tunnelit, mida kunagi teel ei olnud.
Jälgige paketti sillalt välja
Sillal olev konteiner saadab oma paketi oma vaikelüüsile, milleks on hosti sildliides. Seejärel edastab host paketi ja tõlgib vaikekonfiguratsioonis lähteaadressi enda omaks enne, kui pakett väljub. Just see tõlkeline samm nurjab poliitika vaikselt.
Selleks ajaks, kui pakett tunneli lõpp-punkti jõuab, kannab see hosti aadressi. Iga reegel, poliitikamarsruut või jagatud tunneli otsus, mis põhineb konteineri algsel aadressil, lakkab sobimast, ja kahte erinevatest väljapääsudest väljuma pidanud konteinerit ei saa ainult allika järgi eristada. Kui vajate marsruutimist konteineri kaupa, peab otsus sündima enne tõlget või nimeruumis, mida te kontrollite.
Docker haldab neid reegleid ise, ükskõik millise tulemüüri taustarakendusega daemon seadistati. Käsitsi kirjutatud reeglid väljaspool edastatava liikluse toetatud konksu, DOCKER-USER, võidakse daemoni taaskäivitamisel või hosti uuendamisel ümber järjestada või kõrvale jätta. Dockeri paketifiltri dokumentatsioon näitab ahelate järjekorda; praktiline mõte on see, et iga reegel vajab omanikku ja uuesti laadimise teed, mida olete tõesti katsetanud.
Testige kahte süsteemi eraldi
Tõendid ühest nimeruumist ei ütle teise kohta midagi. VPN-konteineri sees käivitatud päring tõestab, et tunnel töötab selle konteineri jaoks. See ei ole tõend hosti kohta, ja sama käsk --network host konteinerist ei ole tõend silla kohta.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'Seejärel korrake testi päris rakenduse konteineris, mitte sarnases kujutises. Rakendus võib kanda lisamarsruuti, puhverserveri keskkonnamuutujat või teistsugust resolverit, ja igaüks neist muudab vastust. Kontrollige iga kord nime lahendamist ja teist aadressipere: kasutaja määratud sildadel olevad konteinerid lahendatakse Dockeri sisseehitatud resolveri kaudu aadressil 127.0.0.11, ja silla IPv6 vaikemarsruut võib liikluse välja kanda, samal ajal kui tegelete ainult IPv4 tunneli testimisega.
Lugege mustrit enne, kui puudutate mandaate
Kui host töötab ja konteiner mitte, on põhjus peaaegu alati struktuurne, ja võtmete vahetamine või kliendi uuesti paigaldamine raiskab pärastlõuna. Sorteerige kõigepealt sümptom ja parandus nimetab end tavaliselt ise.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
Kattuvuse rida väärib omaette lauset. VPN-profiil, mis surub marsruudi 172.17.0.0/16 jaoks või 10.0.0.0/8 jaoks, mis juhtub sisaldama teie silla prefiksit, paneb tunneli konteineri alamvõrku nõudma, ja tõlgitud aadressidele saabuvad vastused lähevad vales suunas või kaovad. Dockeri võrgu ümbernummerdamine on tavaliselt puhtam kui erandite kogumine.
Tehke katvus selgesõnaliseks ja siis rikkuge see meelega
Kaks lahendust peavad ülevaatusele vastu. Jagage VPN-konteineri nimeruumi ja iga kaetud töökoormus kasutab ühte tunnelit ühe taaskäivituse piiriga, mis on lihtne seni, kuni üks teenus vajab teistsugust väljapääsu või oma DNS-teed. Või suunake konteinerite võrk hosti VPN-lüüsile: edastamine lubatud, silla prefiks suunatud tunnelile, tagasiliiklus selgesõnaliselt käsitletud. See ostab kontrolli võrgu kaupa ja maksab teile reeglistiku, mida peate daemoni ja kliendi uuenduste käigus hoidma.
Ükskõik kuidas, test, mis loeb, on tõrkejuhtum. Peatage tunnel, kui konteineri päring on teel, ja vaadake, kuhu pakett läheb. Kui see langeb tagasi otse teele, ei olnud katvus kunagi jõustatud, sest kliendi kill switch juhib kliendi enda liiklust, mitte sillalt edastatud pakette. Seejärel taaskäivitage daemon ja host ning kinnitage tulemus teist korda; just sel hetkel kaovad käsitsi kirjutatud reeglid.
Enne kui nimetate selle valmis, kinnitage neli asja: tunneli liides on samas nimeruumis kui liiklus, konteineri test jooksis päris konteineri sees, nime lahendamine ja mõlemad aadressiperede kontrolliti, ja tunneli tõrketest ebaõnnestub endiselt suletult. Seejärel kirjutage üles tulemüüri taustarakendus, kliendi versioon ja iga reegli omanik. Just see kirje hoiab ära, et järgmine uuendus jätab kohale dokumenteerimata segu vanadest eeldustest.