Trafiko de Docker-ujoj preterpasas la gastigan VPN: kiel kontroli

Via retumilo sur la gastiganto montras la eliran adreson de la VPN, la ujo raportas vian hejman konekton, kaj iu nomas tion liko. Nenio likis. Gastiga tunelo estas aro da interfacoj, itineroj kaj reguloj, kiuj apartenas al la reta nomspaco de la gastiganto, kaj ujo sur ponto estas alia nomspaco kun sia propra defaŭlta itinero. Mi sidis sur Compose-stako, kie la VPN-kliento estis konektita dum semajnoj kaj eĉ ne unu uja paketo iam eniris ĝin.

Kontrolu la nomspacon antaŭ la ikono en la sistemopleto

Nomspacoj estas la tuta argumento. Kiam Docker lanĉas ujon sur ponta reto, ĝi kreas retan nomspacon, alfiksas unu finon de veth-paro en ĝin, kaj donas al tiu nomspaco adreson kaj defaŭltan itinero. La tunela interfaco, kiel ajn ĝi nomiĝas, loĝas en la nomspaco de la gastiganto. Trafiko ene de la ujo ne povas vidi ĝin, kaj neniu klienta agordo ŝanĝas tion de ekstere.

Du subtenataj movoj eligas vin el la izoliteco. --network host metas la ujon en la nomspacon de la gastiganto, do ĝi heredas la itinerojn de la gastiganto kaj sekve la tunelon. --network container:vpn kunhavas la nomspacon de alia ujo, kaj tiel plej multaj flankujaj dezajnoj sendas laborŝarĝon tra VPN-ujo. Ambaŭ estas eksplicitaj elektoj; kutime nur unu el ili estas tio, kion celis la persono, kiu instalas.

Gastiga reĝimo ne estas senpaga ĝisdatigo. La ujo ĉesas havi propran adreson, publikigo de pordoj ĉesas validi, kaj procezo tenanta NET_ADMIN tie povas reskribi la itinaron de la gastiganto. Akcepti tion povas esti la ĝusta decido. Supozi, ke ĝi jam estas ŝaltita, estas kiel homoj pasigas vesperon senerarigante tunelon, kiu neniam estis en la vojo.

Sekvu la paketon for de la ponto

Ponta ujo sendas sian paketon al sia defaŭlta kluzo, kiu estas la ponta interfaco sur la gastiganto. La gastiganto tiam plusendas la paketon kaj, en la defaŭlta agordo, tradukas la fontan adreson al sia propra antaŭ ol la paketo eliras. Ĝuste tiu traduka paŝo silente venkas politikon.

Kiam la paketo atingas la finpunkton de la tunelo, ĝi portas la adreson de la gastiganto. Ĉiu regulo, politika itinero aŭ decido pri dividita tunelo bazita sur la origina adreso de la ujo ĉesas kongrui, kaj du ujoj destinitaj eliri tra malsamaj elirejoj ne povas esti distingitaj nur per la fonto. Se vi bezonas itinaron por ĉiu ujo, la decido devas okazi antaŭ la traduko aŭ ene de nomspaco, kiun vi kontrolas.

Docker mem prizorgas ĉi tiujn regulojn, per kiu ajn fajroŝirma malantaŭaĵo la demono estis agordita. Mane skribitaj reguloj ekster la subtenata hoko por plusendita trafiko, DOCKER-USER, povas esti reordigitaj aŭ forigitaj, kiam la demono restartas aŭ la gastiganto ĝisdatiĝas. La dokumentaro de Docker pri paketa filtrado montras la ordon de la ĉenoj; la praktika punkto estas, ke ĉiu regulo bezonas posedanton kaj reŝargan vojon, kiun vi efektive testis.

Testu la du sistemojn aparte

Pruvo el unu nomspaco diras nenion pri la alia. Peto lanĉita ene de la VPN-ujo pruvas, ke la tunelo funkcias por tiu ujo. Ĝi ne estas pruvo pri la gastiganto, kaj la sama komando lanĉita el --network host-ujo ne estas pruvo pri la ponto.

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

Poste ripetu la teston ene de la reala aplikaĵa ujo anstataŭ simila bildo. La aplikaĵo povas porti plian itinero, prokuran medivariablon aŭ alian solvilon, kaj ĉiu el tiuj ŝanĝas la respondon. Kontrolu nomrezolucion kaj la duan adresan familion ĉiufoje: ujoj sur uzant-difinitaj pontoj solviĝas per la enkonstruita solvilo de Docker ĉe 127.0.0.11, kaj defaŭlta itinero IPv6 sur la ponto povas elporti trafikon, dum vi okupiĝas pri testado de tunelo nur IPv4.

Legu la ŝablonon antaŭ ol tuŝi akreditaĵojn

Kiam la gastiganto funkcias kaj la ujo ne, la kaŭzo estas preskaŭ ĉiam struktura, kaj rotacii ŝlosilojn aŭ reinstali la klienton malŝparas posttagmezon. Unue ordigu la simptomon, kaj la riparo kutime nomas sin mem.

La vico pri koincido meritas propran frazon. VPN-profilo, kiu puŝas itinero por 172.17.0.0/16, aŭ por 10.0.0.0/8, kiu hazarde enhavas vian pontan prefikson, igas la tunelon postuli la ujan subreton, kaj respondoj al tradukitaj adresoj iros malĝustan direkton aŭ malaperos. Renumeri la Docker-reton kutime pli puras ol amasigi esceptojn.

Faru la kovradon eksplicita, poste rompu ĝin intence

Du dezajnoj eltenas revizion. Kunhavigu la nomspacon de la VPN-ujo kaj ĉiu kovrita laborŝarĝo uzas unu tunelon kun unu restarta limo, kio estas simpla ĝis unu servo bezonas alian elirejon aŭ sian propran DNS-vojon. Aŭ itinigu la ujan reton al VPN-kluzo sur la gastiganto: plusendado ŝaltita, la ponta prefikso direktita al la tunelo, revena trafiko eksplicite traktita. Tio aĉetas regadon por ĉiu reto kaj kostas al vi regularon prizorgendan tra demonaj kaj klientaj ĝisdatigoj.

Ĉiel ajn, la testo, kiu gravas, estas la malsukcesa kazo. Haltigu la tunelon kun uja peto en flugo kaj observu, kien la paketo iras. Se ĝi refalas al la rekta vojo, la kovrado neniam estis trudita, ĉar kill switch de kliento regas la propran trafikon de la kliento kaj ne plusenditajn paketojn de ponto. Poste restartu la demonon kaj la gastiganton kaj konfirmu la rezulton duan fojon; tio estas la momento, kiam mane skribitaj reguloj malaperas.

Antaŭ ol nomi ĝin finita, konfirmu kvar aferojn: la tunela interfaco estas en la sama nomspaco kiel la trafiko, la uja testo kuris ene de la reala ujo, nomrezolucio kaj ambaŭ adresaj familioj estis kontrolitaj, kaj la tunela malsukcesa testo ankoraŭ malsukcesas fermite. Poste notu la fajroŝirman malantaŭaĵon, la klientan version kaj la posedanton de ĉiu regulo. Tiu rikordo estas tio, kio malhelpas la sekvan ĝisdatigon lasi nedokumentitan miksaĵon de malnovaj supozoj.