Docker konteinerių srautas apeina pagrindinio kompiuterio VPN: kaip patikrinti
Pagrindinio kompiuterio VPN apima tik jo tinklo vardų erdvę. Šiais patikrinimais išsiaiškinsite, ar tiltelio konteinerių srautas patenka į tunelį, ar išeina tiesiogiai.
Naršyklė pagrindiniame kompiuteryje rodo VPN išėjimo adresą, konteineris praneša apie jūsų namų ryšį, o kažkas tai vadina nutekėjimu. Niekas nenutekėjo. Pagrindinio kompiuterio tunelis yra sąsajų, maršrutų ir taisyklių rinkinys, priklausantis jo tinklo vardų erdvei, o konteineris ant tiltelio yra kita vardų erdvė su savo numatytuoju maršrutu. Esu sėdėjęs prie Compose krūvos, kur VPN klientas buvo prijungtas savaitėmis ir nė vienas konteinerio paketas niekada nebuvo į ją patekęs.
Patikrinkite vardų erdvę prieš dėklų juostos piktogramą
Vardų erdvės yra visas argumentas. Kai Docker paleidžia konteinerį tiltelio tinkle, jis sukuria tinklo vardų erdvę, prijungia vieną veth poros galą į ją ir suteikia tai erdvei adresą bei numatytąjį maršrutą. Tunelio sąsaja, kad ir kaip ji vadinasi, gyvena pagrindinio kompiuterio vardų erdvėje. Srautas konteinerio viduje negali jos matyti, ir jokia kliento nuostata to nekeičia iš išorės.
Du palaikomi žingsniai išveda jus iš izoliacijos. --network host patalpina konteinerį pagrindinio kompiuterio vardų erdvėje, todėl jis paveldi jo maršrutus ir kartu tunelį. --network container:vpn bendrina kito konteinerio vardų erdvę, ir būtent taip dauguma sidecar sprendimų siunčia darbo krūvį per VPN konteinerį. Abu yra aiškūs pasirinkimai; paprastai tik vienas jų yra tai, ką turėjo omenyje diegiantis asmuo.
Pagrindinio kompiuterio režimas nėra nemokamas atnaujinimas. Konteineris nustoja turėti savo adresą, prievadų skelbimas nustoja galioti, o ten turintis NET_ADMIN procesas gali perrašyti pagrindinio kompiuterio maršrutus. Tai priimti gali būti teisingas sprendimas. Manyti, kad jis jau įjungtas, yra būdas, kuriuo žmonės praleidžia vakarą derindami tunelį, kuris niekada nebuvo kelyje.
Sekite paketą nuo tiltelio
Tiltelio konteineris siunčia savo paketą į savo numatytąją tinklų sietuvą, kuri yra tiltelio sąsaja pagrindiniame kompiuteryje. Tada pagrindinis kompiuteris persiunčia paketą ir numatytojoje konfigūracijoje prieš paketui išeinant išverčia šaltinio adresą į savąjį. Būtent šis vertimo žingsnis tyliai panaikina politiką.
Kai paketas pasiekia tunelio galinį tašką, jis neša pagrindinio kompiuterio adresą. Bet kuri taisyklė, politikos maršrutas ar skaidyto tunelio sprendimas, pagrįstas pradiniu konteinerio adresu, nustoja sutapti, o dviejų konteinerių, skirtų išeiti skirtingais išėjimais, neįmanoma atskirti vien pagal šaltinį. Jei jums reikia maršrutizavimo pagal konteinerį, sprendimas turi būti priimtas prieš vertimą arba jūsų valdomoje vardų erdvėje.
Docker pats prižiūri šias taisykles per tą ugniasienės backend, su kuriuo buvo sukonfigūruotas daemonas. Ranka rašytos taisyklės už palaikomo persiunčiamo srauto kabliuko, DOCKER-USER, gali būti perrikiuotos arba pašalintos, kai daemonas paleidžiamas iš naujo arba atnaujinamas pagrindinis kompiuteris. Docker paketų filtravimo dokumentacija rodo grandinių tvarką; praktinė mintis ta, kad kiekvienai taisyklei reikia savininko ir perkrovimo kelio, kurį tikrai išbandėte.
Išbandykite dvi sistemas atskirai
Įrodymai iš vienos vardų erdvės nieko nesako apie kitą. Užklausa, įvykdyta VPN konteineryje, įrodo, kad tunelis veikia tam konteineriui. Tai ne įrodymas apie pagrindinį kompiuterį, o ta pati komanda, įvykdyta --network host konteineryje, nėra įrodymas apie tiltelį.
# 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'Tada pakartokite testą tikrame programos konteineryje, o ne panašiame atvaizde. Programa gali turėti papildomą maršrutą, tarpinio serverio aplinkos kintamąjį ar kitokį resolverį, ir kiekvienas iš jų keičia atsakymą. Kiekvieną kartą patikrinkite vardų skyrimą ir antrąją adresų šeimą: konteineriai vartotojo apibrėžtuose tilteliuose sprendžiami per Docker integruotą resolverį adresu 127.0.0.11, o tiltelio IPv6 numatytasis maršrutas gali išnešti srautą, kol jūs užsiėmę tik IPv4 tunelio testavimu.
Perskaitykite modelį prieš liesdami prisijungimo duomenis
Kai pagrindinis kompiuteris veikia, o konteineris ne, priežastis beveik visada struktūrinė, o raktų keitimas ar kliento perdiegimas sugaišta popietę. Pirmiausia surikiuokite simptomą, ir pataisymas paprastai pats save įvardija.
| 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 |
Persidengimo eilutė nusipelno savo sakinio. VPN profilis, kuris stumia maršrutą 172.17.0.0/16 arba 10.0.0.0/8, kuriame atsitiktinai yra jūsų tiltelio priešdėlis, priverčia tunelį pretenduoti į konteinerių potinklį, o atsakymai į išverstus adresus nukryps ne ta kryptimi arba dings. Docker tinklo pernumeravimas paprastai švaresnis nei išimčių kaupimas.
Padarykite aprėptį aiškią, tada tyčia ją sulaužykite
Du sprendimai atlaiko peržiūrą. Bendrinkite VPN konteinerio vardų erdvę, ir kiekvienas padengtas darbo krūvis naudoja vieną tunelį su viena paleidimo iš naujo riba, kas paprasta tol, kol vienai paslaugai neprireikia kito išėjimo ar savo DNS kelio. Arba nukreipkite konteinerių tinklą į VPN tinklų sietuvą pagrindiniame kompiuteryje: persiuntimas įjungtas, tiltelio priešdėlis nukreiptas į tunelį, grįžtamasis srautas tvarkomas aiškiai. Tai nuperka kontrolę pagal tinklą ir kainuoja taisyklių rinkinį, kurį reikia prižiūrėti per daemono ir kliento atnaujinimus.
Kad ir kaip būtų, svarbiausias testas yra gedimo atvejis. Sustabdykite tunelį, kai konteinerio užklausa skrieja, ir pažiūrėkite, kur paketas nueina. Jei jis grįžta į tiesioginį kelią, aprėptis niekada nebuvo užtikrinta, nes kliento kill switch valdo paties kliento srautą, o ne persiunčiamus paketus iš tiltelio. Tada paleiskite daemoną ir pagrindinį kompiuterį iš naujo ir antrą kartą patvirtinkite rezultatą; tai akimirka, kai ranka rašytos taisyklės dingsta.
Prieš vadindami tai baigtu, patvirtinkite keturis dalykus: tunelio sąsaja yra toje pačioje vardų erdvėje kaip srautas, konteinerio testas buvo atliktas tikrame konteineryje, vardų skyrimas ir abi adresų šeimos buvo patikrintos, o tunelio gedimo testas vis dar nepavyksta uždarai. Tada užsirašykite ugniasienės backend, kliento versiją ir kiekvienos taisyklės savininką. Būtent šis įrašas neleidžia kitam atnaujinimui palikti nedokumentuoto senų prielaidų mišinio.