It netwurk fan in VPN-container diele: wat der mei DNS bart

It dielen fan ’e netwurknammeromte fan in VPN-container jout jo applikaasje de ynterfaces en rûtes fan de tunnel. It jout it de resolver fan de tunnel net, en ek gjin gearfoege kopy fan wat dan ek op de host. Dat gat liedt ta in tige spesifike flater: iepenbiere nammen wurde oplost, ynterne net, en de app dy’t mislearret liket de ferkearde DNS-tsjinner te brûken, omdat dat sa is. De reparaasje is meastentiids lytser as de diagnose suggerearret.

Stap 1: Test fan ’e app, net fan ’e host

Rin de opsoch binnen de container dy’t it probleem hat, net op ’e host en net yn in browser. docker exec app-container getent hosts db.internal beantwurdet de iennige fraach dy’t fan belang is: wat de resolver fan dit proses werombringt.

As de host de namme oplost en de container net, hawwe jo de flater fûn. Alles hjirnei is it kiezen fan in stipene manier om it te reparearjen.

Stap 2: Lês it stipene model fan ’e runtime

Docker syn netwurkdokumintaasje skriuwt beheiningen op oer DNS-flagen foar containers dy’t de netwurkmody fan in oare container diele. Yn Compose network_mode: service:vpn bynt de app oan ’e nammeromte fan ’e VPN-container, en per tsjinst dns gedrage de ynstellingen har net sa as by in gewoane tsjinst. De oplossing dy’t jo krije is dy’t de dielde nammeromte hat.

Troch de brûker definiearre brêgenetwurken brûke ek Docker syn ynboude DNS oars as de standertbrêge. Dêrom kin in dns klausule dy’t út in wurkjend brêgefoarbyld kopyeare is, yn in dielde stack hielendal neat dwaan. Kontrolearje de opstelling foar’t jo de klausule kopyearje.

In loopback-adres ferwiist altyd nei de oanbelangjende netwurk kontekst. Binnen in dielde nammeromte is 127.0.0.1 net de resolver fan ’e host.

Stap 3: Folgje de fraach nei syn ûntfanger

Lês de resolver-konfiguraasje fan ’e app, dan alle applikaasjespesifike fersifere DNS dy’t de app meinimt, omdat in app dy’t syn eigen resolver draait it bestân negearret dat jo bewurke hawwe. Kontrolearje dan oft de keazen resolver berikber is ûnder de rûtes en it firewallbelied fan ’e VPN. In resolveradres oan ’e oare kant fan ’e tunnel is nutteleas as de nammeromte dêr gjin rûte nei hat. Befêstigje de ûntfanger foar’t jo hokker bestân dan ek bewurkje.

In IP-kontrôlepagina yn in browser kin jo net fertelle wêr’t nammeftragen hinne gien binne. It fertelt wêr’t ien HTTP-ferbining hinne gien is.

Stap 4: Reparearje de twa flaterklassen ferskillend

As tsjinstnammen mislearje wylst iepenbiere nammen wurkje, is it probleem tsjinstûntdekking binnen it containernetwurk, net de list fan iepenbiere resolvers. It feroarjen fan elk iepenbier DNS-adres sil gjin records meitsje dêr’t it ûntdekkingsmeganisme fan it netwurk nea om frege is.

As beide klassen mislearje, begjin dan mei de berikberens fan ’e resolver. As mar ien mislearret, begjin dan mei it ûntdekkingsmeganisme. De twa hawwe ferskillende eigeners, dêrom dekt ien reparaasje nea beide.

Stap 5: Test op ’e nij nei werommeitsjen

Feroarje de konfiguraasje fia it stipene meganisme fan ’e runtime, meitsje dan de containers op ’e nij yn stee fan bestannen binnen in draaiende te bewurkjen. Test in fars priveename, in fars iepenbiere namme en it applikaasjeferkiezen dat op ’e opsoch folget. In bewurking oan /etc/resolv.conf binnen in container ferdwynt by werommeitsjen en sil jo oertsjûgje dat de reparaasje wurke hat doe’t dat net sa wie.

Skriuw de eigner fan ’e resolver en de ferwachte nammeromte njonken de definysje fan it dielde netwurk. De folgjende persoan sil beide nedich hawwe.