Dev Container ફક્ત VPN દ્વારા ઉપલબ્ધ હોસ્ટ સુધી પહોંચતું નથી: ક્યાં જોવું

ખાનગી API તમારા ડેસ્કટોપ બ્રાઉઝરમાં ખૂલે છે અને ડેવલપમેન્ટ કન્ટેનરમાં નિષ્ફળ જાય છે. આ વિરોધાભાસ નથી, અને ભાગ્યે જ VPN પોતે કારણ હોય છે. બ્રાઉઝરની વિનંતી અને નિષ્ફળ વિનંતી બે અલગ પ્રક્રિયાઓએ બનાવી છે, અલગ resolver, proxy અને રૂટ સાથે, અને ઘણી વાર સંપૂર્ણપણે અલગ નેટવર્ક નામસ્થાનમાંથી. “મારા લેપટોપ પર” એટલે Windows હોસ્ટ, WSL ડિસ્ટ્રિબ્યુશન, Docker Desktop વર્ચ્યુઅલ મશીન અને તે VM ની અંદરનું કન્ટેનર હોઈ શકે — ચાર સંદર્ભ, જેમાંથી દરેક એક જ હોસ્ટનામનો અલગ જવાબ આપી શકે છે. એક પણ સેટિંગને અડકતા પહેલાં નિષ્ફળ પ્રક્રિયા કયો વાપરે છે તે શોધો.

સેટિંગ બદલતા પહેલાં પ્રક્રિયા શોધો

VPN ક્લાયન્ટથી નહીં, કન્ટેનર એન્જિનથી શરૂ કરો. પૂછો કે કમાન્ડ લાઇન કયા સંદર્ભ સાથે વાત કરે છે અને તે એન્જિન કયા ઓપરેટિંગ સિસ્ટમ પર ચાલે છે, કારણ કે ડેસ્કટોપ VM દ્વારા સંચાલિત Linux કન્ટેનર સ્થાનિક ડેમન દ્વારા સંચાલિત કન્ટેનર કરતાં અલગ માર્ગ લે છે:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windows પર, wsl -l -v કહે છે કે ડિસ્ટ્રિબ્યુશન WSL 2 હેઠળ ચાલે છે કે નહીં, જે તેને તેના પોતાના વર્ચ્યુઅલ સ્વિચ પાછળ મૂકે છે. એ જ વિગત નક્કી કરે છે કે કન્ટેનર હોસ્ટના રૂટિંગ ટેબલને વહેંચે છે કે NAT પાછળ બેસે છે જેને હોસ્ટ સુધી પહોંચવા ફોરવર્ડ કરેલો પોર્ટ કે હોસ્ટનામ જોઈએ.

એક વિનંતી સ્થિર રાખો અને સરખાવો

ખાનગી હોસ્ટ પર એક હાનિરહિત એન્ડપોઇન્ટ પસંદ કરો અને દરેક સરખામણી માટે તેનો ઉપયોગ કરો: બ્રાઉઝરમાંથી, હોસ્ટ ટર્મિનલમાંથી, WSL ડિસ્ટ્રિબ્યુશનમાંથી અને કન્ટેનરની અંદરથી. દરેક પ્રયાસ માટે ચાર વસ્તુ નોંધો: ઉકેલાયેલું સરનામું, proxy વપરાયો કે નહીં, નિષ્ફળતાનો વર્ગ અને વીતેલો સમય. નામ શોધ, કનેક્શન સ્થાપવું, TLS માન્યતા અને HTTP સ્થિતિ — આ ચાર અલગ સમસ્યાઓ છે, અને તેમને “કામ કરતું નથી” માં ભેળવવાથી એક સવાર બગડે છે.

સરખામણી નિષ્ફળ થતા કન્ટેનરની અંદર જ ચલાવો, ટાઇમઆઉટ સાથે, જેથી શાંત ફાયરવોલ ટર્મિનલને મિનિટો સુધી ન રોકે. નવું કન્ટેનર એન્જિનનો નેટવર્ક સંદર્ભ ફરી બનાવે છે, પણ એપ્લિકેશન કન્ટેનરનું નામસ્થાન, proxy ચલ કે resolver નહીં, તેથી સાચા કન્ટેનરમાં docker exec કરવું એ જ અધિકૃત પરીક્ષણ છે, અને સાઇડકાર ફક્ત એ અલગ કરવાનો ઉપાય છે કે ફરક એન્જિનમાં છે કે કન્ટેનરમાં:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine બેઝ ઇમેજમાં busybox છે અને curl નથી, અને આ જ એવી વિગત છે જે કોપી કરેલા ડાયગ્નોસ્ટિક બ્લોકને નિષ્ફળ બનાવે છે: ક્લાયન્ટ સાથેનું ઇમેજ પસંદ કરો, અથવા તેને એ જ રનમાં ઉમેરો. સંબંધ વગરની સાર્વજનિક સાઇટ સાથેની સરખામણી કંઈ અલગ કરતી નથી. જો કન્ટેનરમાંથી https://example.com કામ કરે, તો તમે ફક્ત એ જાણ્યું કે કન્ટેનરને ઇન્ટરનેટ એક્સેસ છે, અને એ નહીં કે તે ટનલ દ્વારા ખાનગી સરનામે પહોંચે છે કે નહીં. તે જ રીતે, નવું ટર્મિનલ ખોલવું ફક્ત એ સાબિત કરે છે કે નવું ટર્મિનલ કામ કરે છે, એ નહીં કે તે નિષ્ફળ ગયેલી એપ્લિકેશન સાથે એક જ રનટાઇમ વહેંચે છે.

Docker Desktop VPN સાથે કામ કરી શકે છે

Docker નું પોતાનું VPN અને હોસ્ટ કનેક્ટિવિટી વિશેનું દસ્તાવેજીકરણ આને સમર્થિત સેટઅપ તરીકે વર્ણવે છે, અને પ્રામાણિક સારાંશ એ છે કે તે કામ કરે છે, આપોઆપ તૂટેલું નથી. એવું ન માનો કે ડેસ્કટોપ VM ડિઝાઇનથી જ હોસ્ટની ટનલ ટાળે છે; ઘણા સેટઅપમાં ટ્રાફિક હોસ્ટની ટનલને યોગ્ય રીતે અનુસરે છે, અને તેથી જ “Docker VPN ને અવગણે છે” એવી દંતકથા આત્મવિશ્વાસપૂર્ણ અને ખોટી સલાહ આપે છે.

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

સરનામા ઓવરલેપ અને MTU અલગ નિષ્ફળતાઓ છે

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

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

બીજી MTU સમસ્યા છે. જો કનેક્શન સ્થપાય અને TLS પૂર્ણ થાય પણ મોટા પ્રતિભાવો અટકી જાય, તો તમારી પાસે પેકેટ-કદની સમસ્યા છે, અધિકૃતિની નહીં, અને DNS રેકોર્ડ બદલવાથી તે ક્યારેય ઠીક થશે નહીં. કંઈપણ બદલતા પહેલાં નાની અને મોટી વિનંતી સાથે પરીક્ષણ કરો અને બંને પરિણામ નોંધો.

ઓવરલેપનો ઉપાય બીજું કન્ટેનર સબનેટ કે મર્યાદિત રૂટ છે, જે સરનામા યોજનાનો માલિક પસંદ કરે. MTU અટકવાનો ઉપાય ટનલ કે ઇન્ટરફેસનું MTU એવા મૂલ્ય સુધી ઘટ્ટ કે ઘટાડવું છે જે માર્ગમાં ટકી રહે, અને તે તમે નિયંત્રિત કરો છો તે સ્તર પર લાગુ કરવું.

Proxy રૂપરેખા પ્રક્રિયા પ્રમાણે છે, મશીન પ્રમાણે નહીં

કન્ટેનરની અંદર, localhost તે કન્ટેનરના પોતાના નેટવર્ક સંદર્ભનું નામ છે, તેથી હોસ્ટ પર ચાલતો proxy ત્યાં તે નામથી પહોંચી શકાતો નથી. Docker Desktop હોસ્ટ એક્સેસ માટે host.docker.internal પૂરું પાડે છે, અને Linux પર તમે તેને --add-host=host.docker.internal:host-gateway વડે સ્પષ્ટ રીતે ઉમેરો છો. કોઈપણ રીતે, તે નામ તમને હોસ્ટ સુધીનો રૂટ આપે છે; તે proxy સેવા બનાવતું નથી કે તેનો ઉપયોગ કરવાની પરવાનગી પણ આપતું નથી.

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

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