VPN કન્ટેનરનું નેટવર્ક શેર કરવું: DNS સાથે શું થાય છે

VPN કન્ટેનરનું નેટવર્ક નામસ્થાન શેર કરવાથી તમારી એપ્લિકેશનને ટનલના ઇન્ટરફેસ અને રૂટ મળે છે. તે તેને ટનલનું રિઝોલ્વર આપતું નથી, કે હોસ્ટ પર બીજું કંઈપણ હોય તેની એકીકૃત નકલ પણ નહીં. આ ખાલીપો ખૂબ ચોક્કસ નિષ્ફળતા ઉત્પન્ન કરે છે: જાહેર નામો ઉકેલાય છે, આંતરિક નામો ઉકેલાતા નથી, અને જે એપ નિષ્ફળ જાય છે તે ખોટા DNS સર્વરનો ઉપયોગ કરતી હોય તેવું લાગે છે, કારણ કે તે ખરેખર કરે છે. સુધારો સામાન્ય રીતે નિદાન સૂચવે તેના કરતાં નાનો હોય છે.

પગલું 1: હોસ્ટ પરથી નહીં, એપ પરથી પરીક્ષણ કરો

જે કન્ટેનરમાં સમસ્યા છે તેની અંદર લુકઅપ ચલાવો, હોસ્ટ પર નહીં અને બ્રાઉઝરમાં નહીં. docker exec app-container getent hosts db.internal એકમાત્ર મહત્વના પ્રશ્નનો જવાબ આપે છે: આ પ્રક્રિયાનું રિઝોલ્વર શું પરત કરે છે.

જો હોસ્ટ નામ ઉકેલે અને કન્ટેનર ન ઉકેલે, તો તમે ખામી શોધી કાઢી છે. આ પછીનું બધું તેને સુધારવાની સમર્થિત રીત પસંદ કરવાનું છે.

પગલું 2: રનટાઇમનું સમર્થિત મોડેલ વાંચો

Dockerનું નેટવર્ક દસ્તાવેજીકરણ બીજા કન્ટેનરની નેટવર્ક મોડ શેર કરતા કન્ટેનર માટે DNS ફ્લેગ પર નિયંત્રણો નોંધે છે. Composeમાં network_mode: service:vpn એપને VPN કન્ટેનરના નામસ્થાન સાથે બાંધે છે, અને દરેક સેવા માટે dns સેટિંગ્સ સામાન્ય સેવાની જેમ વર્તતી નથી. તમે જે ઉકેલ મેળવો છો તે શેર કરેલ નામસ્થાન પાસે જે છે તે જ છે.

વપરાશકર્તા-વ્યાખ્યાયિત બ્રિજ નેટવર્ક પણ Dockerના એમ્બેડેડ DNSનો ડિફોલ્ટ બ્રિજ કરતાં અલગ રીતે ઉપયોગ કરે છે. તેથી જ dns કાર્યરત બ્રિજ ઉદાહરણમાંથી કોપી કરેલી કલમ શેર કરેલ સ્ટેકમાં કંઈ જ કરી શકતી નથી. કલમ કોપી કરતા પહેલાં ગોઠવણ તપાસો.

લૂપબેક સરનામું હંમેશા સંબંધિત નેટવર્ક સંદર્ભનો ઉલ્લેખ કરે છે. શેર કરેલ નામસ્થાનની અંદર, 127.0.0.1 હોસ્ટનું રિઝોલ્વર નથી.

પગલું 3: ક્વેરીને તેના પ્રાપ્તકર્તા સુધી અનુસરો

એપની રિઝોલ્વર ગોઠવણી વાંચો, પછી એપ સાથે આવતા કોઈપણ એપ-વિશિષ્ટ એન્ક્રિપ્ટેડ DNS વાંચો, કારણ કે પોતાનું રિઝોલ્વર ચલાવતી એપ તમે સંપાદિત કરેલી ફાઇલને અવગણે છે. પછી તપાસો કે પસંદ કરેલું રિઝોલ્વર VPNના રૂટ અને ફાયરવોલ નીતિ હેઠળ પહોંચી શકાય તેવું છે કે નહીં. ટનલની બીજી બાજુનું રિઝોલ્વર સરનામું નકામું છે જો નામસ્થાનની ત્યાં કોઈ રૂટ ન હોય. કોઈપણ ફાઇલ સંપાદિત કરતા પહેલાં પ્રાપ્તકર્તાની પુષ્ટિ કરો.

બ્રાઉઝરનું IP-તપાસ પૃષ્ઠ તમને કહી શકતું નથી કે નામ ક્વેરીઓ ક્યાં ગઈ. તે કહે છે કે એક HTTP કનેક્શન ક્યાં ગયું.

પગલું 4: બે નિષ્ફળતા વર્ગોને અલગ રીતે સુધારો

જો સેવા નામો નિષ્ફળ જાય જ્યારે જાહેર નામો કામ કરે, તો સમસ્યા કન્ટેનર નેટવર્કની અંદરની સેવા શોધમાં છે, જાહેર રિઝોલ્વર યાદીમાં નહીં. દરેક જાહેર DNS સરનામું બદલવાથી એવા રેકોર્ડ બનશે નહીં જે નેટવર્કની શોધ પદ્ધતિને ક્યારેય માગવામાં આવ્યા નથી.

જો બંને વર્ગ નિષ્ફળ જાય, તો રિઝોલ્વર સુધીની પહોંચથી શરૂ કરો. જો ફક્ત એક જ નિષ્ફળ જાય, તો શોધ પદ્ધતિથી શરૂ કરો. બંનેના માલિક અલગ છે, તેથી એક સુધારો ક્યારેય બંનેને આવરી લેતો નથી.

પગલું 5: પુનઃનિર્માણ પછી ફરી પરીક્ષણ કરો

રનટાઇમની સમર્થિત પદ્ધતિ દ્વારા ગોઠવણી બદલો, પછી ચાલતા કન્ટેનરની અંદર ફાઇલો સંપાદિત કરવાને બદલે કન્ટેનર ફરી બનાવો. નવું ખાનગી નામ, નવું જાહેર નામ અને લુકઅપ પછીની એપ્લિકેશન વિનંતીનું પરીક્ષણ કરો. /etc/resolv.conf કન્ટેનરની અંદરનું સંપાદન પુનઃનિર્માણ પર અદૃશ્ય થાય છે અને તમને ખાતરી કરાવશે કે સુધારો કામ કરતો હતો જ્યારે તે નહોતો કરતો.

શેર કરેલ નેટવર્ક વ્યાખ્યાની બાજુમાં રિઝોલ્વરનો માલિક અને અપેક્ષિત નામસ્થાન નોંધો. આગલી વ્યક્તિને બંનેની જરૂર પડશે.