Ndarja e rrjetit të një kontejneri VPN: çfarë ndodh me DNS

Ndarja e hapësirës së emrave të rrjetit të një kontejneri VPN i jep aplikacionit tuaj ndërfaqet dhe rrugët e tunelit. Ai nuk i jep zgjidhësin e tunelit, as një kopje të bashkuar të çdo gjëje tjetër në host. Ky boshllëk prodhon një dështim shumë specifik: emrat publikë zgjidhen, ata të brendshëm jo, dhe aplikacioni që dështon duket se përdor serverin e gabuar DNS, sepse vërtet e bën. Riparimi është zakonisht më i vogël sesa sugjeron diagnoza.

Hapi 1: Testoni nga aplikacioni, jo nga hosti

Ekzekutoni kërkimin brenda kontejnerit që ka problemin, jo në host dhe jo në një shfletues. docker exec app-container getent hosts db.internal përgjigjet pyetjes së vetme që ka rëndësi: çfarë kthen zgjidhësi i këtij procesi.

Nëse hosti e zgjidh emrin dhe kontejneri jo, e keni gjetur defektin. Gjithçka pas kësaj është zgjedhja e një mënyre të mbështetur për ta rregulluar.

Hapi 2: Lexoni modelin e mbështetur të runtime-it

Dokumentacioni i rrjetit i Docker regjistron kufizime për flamujt DNS për kontejnerët që ndajnë modalitetin e rrjetit të një kontejneri tjetër. Në Compose network_mode: service:vpn e lidh aplikacionin me hapësirën e emrave të kontejnerit VPN, dhe për çdo shërbim dns cilësimet nuk sillen si në një shërbim të zakonshëm. Zgjidhja që merrni është ajo që ka hapësira e përbashkët e emrave.

Rrjetet e urës të përcaktuara nga përdoruesi gjithashtu përdorin DNS-në e integruar të Docker ndryshe nga ura e parazgjedhur. Prandaj një dns klauzolë e kopjuar nga një shembull ure që funksionon mund të mos bëjë absolutisht asgjë në një stack të përbashkët. Kontrolloni rregullimin përpara se të kopjoni klauzolën.

Një adresë loopback i referohet gjithmonë kontekstit përkatës të rrjetit. Brenda një hapësire të përbashkët emrash, 127.0.0.1 nuk është zgjidhësi i hostit.

Hapi 3: Ndiqni kërkesën deri te marrësi i saj

Lexoni konfigurimin e zgjidhësit të aplikacionit, më pas çdo DNS të kriptuar specifik të aplikacionit që ai sjell, sepse një aplikacion që ekzekuton zgjidhësin e vet injoron skedarin që keni redaktuar. Më pas kontrolloni nëse zgjidhësi i zgjedhur është i arritshëm nën rrugët dhe politikën e firewall-it të VPN. Një adresë zgjidhësi në anën tjetër të tunelit është e padobishme nëse hapësira e emrave nuk ka rrugë drejt saj. Konfirmoni marrësin përpara se të redaktoni çdo skedar.

Një faqe kontrolli IP në shfletues nuk mund t'ju thotë ku shkuan kërkesat për emra. Ju thotë ku shkoi një lidhje HTTP.

Hapi 4: Rregulloni dy klasat e dështimit ndryshe

Nëse emrat e shërbimeve dështojnë ndërsa emrat publikë funksionojnë, problemi është zbulimi i shërbimeve brenda rrjetit të kontejnerëve, jo lista e zgjidhësve publikë. Ndryshimi i çdo adrese publike DNS nuk do të krijojë regjistrime për të cilat mekanizmi i zbulimit të rrjetit nuk është pyetur kurrë.

Nëse të dyja klasat dështojnë, filloni me arritshmërinë e zgjidhësit. Nëse dështon vetëm njëra, filloni me mekanizmin e zbulimit. Të dyja kanë pronarë të ndryshëm, prandaj një riparim nuk mbulon kurrë të dyja.

Hapi 5: Ritestoni pas rikrijimit

Ndryshoni konfigurimin përmes mekanizmit të mbështetur të runtime-it, më pas rikrijoni kontejnerët në vend që të redaktoni skedarë brenda një kontejneri që po ecën. Testoni një emër privat të ri, një emër publik të ri dhe kërkesën e aplikacionit që vjen pas kërkimit. Një ndryshim në /etc/resolv.conf brenda një kontejneri zhduket gjatë rikrijimit dhe do t'ju bindë se riparimi funksionoi kur nuk funksionoi.

Regjistroni pronarin e zgjidhësit dhe hapësirën e pritur të emrave pranë përkufizimit të rrjetit të përbashkët. Personi tjetër do t'i ketë nevojë të dyja.