Kunhavigi la reton de VPN-ujo: kio okazas al DNS

Kunhavigi la retan nomspacon de VPN-ujo donas al via aplikaĵo la interfacojn kaj itinerojn de la tunelo. Ĝi ne donas al ĝi la solvilon de la tunelo, nek kunfanditan kopion de io ajn alia sur la gastiganto. Tiu breĉo produktas tre specifan paneon: publikaj nomoj solviĝas, internaj ne, kaj la aplikaĵo, kiu paneas, aspektas kvazaŭ ĝi uzus la malĝustan DNS-servilon, ĉar ĝi ja uzas ĝin. La riparo estas kutime pli malgranda ol sugestas la diagnozo.

Paŝo 1: Testu el la aplikaĵo, ne el la gastiganto

Rulu la serĉadon ene de la ujo, kiu havas la problemon, ne sur la gastiganto kaj ne en retumilo. docker exec app-container getent hosts db.internal respondas la solan demandon, kiu gravas: kion redonas la solvilo de ĉi tiu procezo.

Se la gastiganto solvas la nomon kaj la ujo ne, vi trovis la paneon. Ĉio poste estas elekto de subtenata maniero ripari ĝin.

Paŝo 2: Legu la subtenatan modelon de la rulmedio

La reta dokumentaro de Docker registras limigojn pri DNS-flagoj por ujoj, kiuj kunhavigas la retan reĝimon de alia ujo. En Compose network_mode: service:vpn ligas la aplikaĵon al la nomspaco de la VPN-ujo, kaj por ĉiu servo dns la agordoj ne kondutas sin tiel, kiel ĉe ordinara servo. La solvo, kiun vi ricevas, estas tiu, kiun havas la komuna nomspaco.

Uzanto-difinitaj pontaj retoj ankaŭ uzas la enkonstruitan DNS de Docker alimaniere ol la implicita ponto. Tial dns klazo kopiita el funkcianta ponta ekzemplo povas fari tute nenion en komuna stako. Kontrolu la aranĝon antaŭ ol kopii la klazon.

Retroiriga adreso ĉiam rilatas al la koncerna reta kunteksto. Ene de komuna nomspaco, 127.0.0.1 ne estas la solvilo de la gastiganto.

Paŝo 3: Sekvu la demandon al ĝia ricevanto

Legu la solvilan agordon de la aplikaĵo, poste ajnan aplikaĵ-specifan ĉifritan DNS, kiun ĝi kunportas, ĉar aplikaĵo, kiu mem rulas solvilon, ignoras la dosieron, kiun vi redaktis. Poste kontrolu, ĉu la elektita solvilo estas atingebla sub la itineroj kaj fajroŝirma politiko de la VPN. Solvila adreso aliflanke de la tunelo estas senutila, se la nomspaco ne havas itineron al ĝi. Konfirmu la ricevanton antaŭ ol redakti iun ajn dosieron.

IP-kontrola paĝo en retumilo ne povas diri al vi, kien iris la nomdemandoj. Ĝi diras, kien iris unu HTTP-konekto.

Paŝo 4: Riparu la du paneoklasojn malsame

Se servonomoj paneas dum publikaj nomoj funkcias, la problemo estas malkovro de servoj ene de la uja reto, ne la listo de publikaj solviloj. Ŝanĝi ĉiun publikan DNS-adreson ne kreos rikordojn, kiujn la malkovra mekanismo de la reto neniam estis petita krei.

Se ambaŭ klasoj paneas, komencu per atingeblo de la solvilo. Se nur unu paneas, komencu per la malkovra mekanismo. La du havas malsamajn posedantojn, tial unu riparo neniam kovras ambaŭ.

Paŝo 5: Retestu post rekreado

Ŝanĝu la agordon per la subtenata mekanismo de la rulmedio, poste rekreu la ujojn anstataŭ redakti dosierojn ene de kuranta. Testu freŝan privatan nomon, freŝan publikan nomon kaj la aplikaĵan peton, kiu sekvas la serĉadon. Ŝanĝo al /etc/resolv.conf ene de ujo malaperas ĉe rekreado kaj konvinkos vin, ke la riparo funkciis, kvankam ĝi ne funkciis.

Notu la posedanton de la solvilo kaj la atendatan nomspacon apud la difino de la komuna reto. La sekva persono bezonos ambaŭ.