Promet vsebnikov Docker obide VPN gostitelja: kako to preveriti

Vaš brskalnik na gostitelju kaže izhodni naslov VPN, vsebnik poroča o vaši domači povezavi in nekdo temu reče uhajanje. Nič ni ušlo. Tunel gostitelja je skupek vmesnikov, poti in pravil, ki pripadajo omrežnemu imenskemu prostoru gostitelja, vsebnik na mostu pa je drug imenski prostor z lastno privzeto potjo. Sedel sem na skladu Compose, kjer je bil odjemalec VPN povezan tedne in vanj ni nikoli prišel niti en paket vsebnika.

Preverite imenski prostor pred ikono v pladnju

Imenski prostori so ves argument. Ko Docker zažene vsebnik v mostovnem omrežju, ustvari omrežni imenski prostor, vanj pripne en konec para veth in temu prostoru dodeli naslov ter privzeto pot. Vmesnik tunela, kakor koli se že imenuje, živi v imenskem prostoru gostitelja. Promet v vsebniku ga ne vidi in nobena nastavitev odjemalca tega ne spremeni od zunaj.

Dve podprti potezi vas spravita iz izolacije. --network host postavi vsebnik v imenski prostor gostitelja, zato podeduje poti gostitelja in s tem tunel. --network container:vpn si deli imenski prostor drugega vsebnika in tako večina zasnov sidecar pošilja delovno obremenitev skozi vsebnik VPN. Oboje so izrecne izbire; običajno je le ena od njiju tisto, kar je imel v mislih tisti, ki namešča.

Način gostitelja ni brezplačna nadgradnja. Vsebnik preneha imeti svoj naslov, objavljanje vrat preneha veljati in proces, ki tam drži NET_ADMIN, lahko prepiše usmerjanje gostitelja. To sprejeti je lahko prava odločitev. Domnevati, da je že vklopljeno, je način, kako ljudje preživijo večer ob razhroščevanju tunela, ki nikoli ni bil na poti.

Sledite paketu z mostu

Vsebnik na mostu pošlje svoj paket svojemu privzetemu prehodu, to je mostovni vmesnik na gostitelju. Gostitelj nato paket posreduje in v privzeti konfiguraciji prevede izvorni naslov v svojega, preden paket odide. Prav ta korak prevajanja tiho izniči politiko.

Ko paket doseže končno točko tunela, nosi naslov gostitelja. Vsako pravilo, politična pot ali odločitev o razdeljenem tunelu, ki temelji na prvotnem naslovu vsebnika, se preneha ujemati, in dveh vsebnikov, namenjenih izhodu skozi različne izhode, ni mogoče ločiti samo po izvoru. Če potrebujete usmerjanje za vsak vsebnik, mora odločitev pasti pred prevajanjem ali v imenskem prostoru, ki ga nadzorujete.

Docker sam vzdržuje ta pravila prek tistega požarnega zidu, s katerim je bil konfiguriran demon. Ročno napisana pravila zunaj podprte kljuke za posredovan promet, DOCKER-USER, se lahko prerazporedijo ali izbrišejo, ko se demon znova zažene ali gostitelj nadgradi. Dockerjeva dokumentacija o filtriranju paketov prikazuje vrstni red verig; praktična poanta je, da vsako pravilo potrebuje lastnika in pot za ponovno nalaganje, ki ste jo resnično preizkusili.

Preizkusite oba sistema ločeno

Dokazi iz enega imenskega prostora ne povedo nič o drugem. Zahteva, izvedena v vsebniku VPN, dokazuje, da tunel deluje za ta vsebnik. To ni dokaz o gostitelju, in isti ukaz, izveden iz vsebnika --network host, ni dokaz o mostu.

# 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'

Nato poskus ponovite v pravem vsebniku aplikacije in ne v podobni sliki. Aplikacija lahko nosi dodatno pot, okoljsko spremenljivko za proxy ali drug razreševalnik, in vsaka od tega spremeni odgovor. Vsakič preverite razreševanje imen in drugo družino naslovov: vsebniki na uporabniško določenih mostovih se razrešujejo prek vgrajenega razreševalnika Dockerja na 127.0.0.11, privzeta pot IPv6 na mostu pa lahko odnese promet ven, medtem ko ste zaposleni s preizkušanjem tunela samo za IPv4.

Preberite vzorec, preden se dotaknete poverilnic

Ko gostitelj deluje in vsebnik ne, je vzrok skoraj vedno strukturni, in vrtenje ključev ali ponovna namestitev odjemalca zapravi popoldne. Najprej razvrstite simptom in popravek se običajno poimenuje sam.

Vrstica o prekrivanju si zasluži svoj stavek. Profil VPN, ki porine pot za 172.17.0.0/16 ali za 10.0.0.0/8, ki slučajno vsebuje predpono vašega mostu, prisili tunel, da si prisvoji podomrežje vsebnikov, in odgovori na prevedene naslove bodo šli v napačno smer ali izginili. Prenumeriranje omrežja Docker je običajno čistejše od kopičenja izjem.

Naredite pokritost izrecno in jo nato namerno zlomite

Dve zasnovi zdržita pregled. Delite imenski prostor vsebnika VPN in vsaka pokrita delovna obremenitev uporablja en tunel z eno mejo ponovnega zagona, kar je preprosto, dokler ena storitev ne potrebuje drugega izhoda ali svoje poti DNS. Ali usmerite omrežje vsebnikov na prehod VPN na gostitelju: posredovanje omogočeno, predpona mostu usmerjena v tunel, povratni promet izrecno obravnavan. To kupi nadzor za vsako omrežje in vas stane nabor pravil, ki ga morate vzdrževati skozi nadgradnje demona in odjemalca.

Kakor koli, preizkus, ki šteje, je primer okvare. Ustavite tunel, medtem ko je zahteva vsebnika na poti, in poglejte, kam gre paket. Če pade nazaj na neposredno pot, pokritost ni bila nikoli uveljavljena, ker kill switch odjemalca upravlja lastni promet odjemalca in ne posredovanih paketov z mostu. Nato znova zaženite demona in gostitelja ter rezultat potrdite še drugič; to je trenutek, ko ročno napisana pravila izginejo.

Preden to razglasite za končano, potrdite štiri stvari: vmesnik tunela je v istem imenskem prostoru kot promet, preizkus vsebnika je potekal v pravem vsebniku, razreševanje imen in obe družini naslovov sta bili preverjeni, in preizkus okvare tunela še vedno ne uspe zaprt. Nato zapišite požarni zid, različico odjemalca in lastnika vsakega pravila. Prav ta zapis preprečuje, da bi naslednja nadgradnja pustila nedokumentirano mešanico starih predpostavk.