VPN-kontin verkon jakaminen: mitä DNS:lle tapahtuu

VPN-kontin verkkonimiavaruuden jakaminen antaa sovelluksellesi tunnelin rajapinnat ja reitit. Se ei anna sille tunnelin resolveria, eikä yhdistettyä kopiota mistään muusta isännällä. Tämä aukko tuottaa hyvin tietyn vian: julkiset nimet ratkeavat, sisäiset eivät, ja epäonnistuva sovellus näyttää käyttävän väärää DNS-palvelinta, koska se käyttää. Korjaus on yleensä pienempi kuin diagnoosi antaa ymmärtää.

Vaihe 1: Testaa sovelluksesta, älä isännältä

Suorita haku ongelmallisen kontin sisällä, älä isännällä äläkä selaimessa. docker exec app-container getent hosts db.internal vastaa ainoaan tärkeään kysymykseen: mitä tämän prosessin resolver palauttaa.

Jos isäntä ratkaisee nimen ja kontti ei, olet löytänyt vian. Kaikki tämän jälkeen on tuetun korjaustavan valintaa.

Vaihe 2: Lue runtimeen tuettu malli

Dockerin verkkodokumentaatio kirjaa rajoituksia DNS-lipuille konteille, jotka jakavat toisen kontin verkkotilan. Composessa network_mode: service:vpn sitoo sovelluksen VPN-kontin nimiavaruuteen, ja palvelukohtaisesti dns asetukset eivät käyttäydy kuten tavallisessa palvelussa. Saamasi ratkaisu on se, joka jaetulla nimiavaruudella on.

Käyttäjän määrittämät siltäverkot käyttävät Dockerin sisäänrakennettua DNS:ää eri tavalla kuin oletussilta. Siksi dns toimivasta siltaesimerkistä kopioitu lauseke ei välttämättä tee jaetussa pinossa yhtään mitään. Tarkista järjestely ennen lausekkeen kopioimista.

Loopback-osoite viittaa aina asiaankuuluvaan verkkokontekstiin. Jaetun nimiavaruuden sisällä 127.0.0.1 ei ole isännän resolver.

Vaihe 3: Seuraa kysely sen vastaanottajalle

Lue sovelluksen resolverin kokoonpano ja sitten mikä tahansa sovelluskohtainen salattu DNS, jonka sovellus tuo mukanaan, koska omaa resolveriaan ajavat sovellus jättää huomiotta muokkaamasi tiedoston. Tarkista sitten, onko valittu resolver saavutettavissa VPN:n reittien ja palomuurikäytännön alla. Resolverin osoite tunnelin toisella puolella on hyödytön, jos nimiavaruudella ei ole reittiä sinne. Vahvista vastaanottaja ennen minkään tiedoston muokkaamista.

Selaimen IP-tarkistussivu ei voi kertoa, minne nimikyselyt menivät. Se kertoo, minne yksi HTTP-yhteys meni.

Vaihe 4: Korjaa kaksi vikaluokkaa eri tavoin

Jos palvelunimet epäonnistuvat julkisten nimien toimiessa, ongelma on konttiverkon sisäisessä palvelunetsinnässä, ei julkisten resolverien luettelossa. Jokaisen julkisen DNS-osoitteen muuttaminen ei luo tietueita, joita verkon etsintämekanismilta ei ole koskaan pyydetty luomaan.

Jos molemmat luokat epäonnistuvat, aloita resolverin saavutettavuudesta. Jos vain toinen epäonnistuu, aloita etsintämekanismista. Näillä kahdella on eri omistajat, siksi yksi korjaus ei koskaan kata molempia.

Vaihe 5: Testaa uudelleen uudelleenluonnin jälkeen

Muuta kokoonpanoa runtimeen tukemalla mekanismilla ja luo kontit sitten uudelleen sen sijaan, että muokkaisit tiedostoja käynnissä olevan sisällä. Testaa tuore yksityinen nimi, tuore julkinen nimi ja sovelluksen pyyntö, joka seuraa hakua. Muokkaus kohteessa /etc/resolv.conf kontin sisällä katoaa uudelleenluonnissa ja vakuuttaa sinut siitä, että korjaus toimi, vaikka se ei toiminut.

Kirjaa resolverin omistaja ja odotettu nimiavaruus jaetun verkon määritelmän viereen. Seuraava henkilö tarvitsee molemmat.