Docker કન્ટેનર VPN પાછળના હોસ્ટ સુધી કેમ પહોંચતું નથી

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

ટનલ કોના નેમસ્પેસની માલિકી હેઠળ છે તે શોધો

macOS અથવા Windows માટે Docker Desktop પર કન્ટેનર Linux વર્ચ્યુઅલ મશીનની અંદર ચાલે છે. ડેસ્કટોપ પર ઇન્સ્ટોલ કરેલ VPN ક્લાયન્ટ ડેસ્કટોપ ઓપરેટિંગ સિસ્ટમમાં ટનલ બનાવે છે, અને વર્ચ્યુઅલ મશીન તેને ક્યારેય જોતું નથી. કોઈપણ કન્ટેનર ગોઠવણી તેને સુધારતી નથી, કારણ કે કન્ટેનરને જે ઇન્ટરફેસની જરૂર પડે તે તેના નેટવર્ક નેમસ્પેસમાં બિલકુલ હોતું નથી.

Linux હોસ્ટ પર ટનલ હોસ્ટ નેમસ્પેસમાં રહે છે, અને બ્રિજ કન્ટેનર સામાન્ય રીતે હોસ્ટની રૂટિંગ ટેબલ દ્વારા બહાર જતી વખતે સ્રોત NAT લાગુ કરીને તેને પહોંચે છે. જ્યારે તે માર્ગ નિષ્ફળ જાય, ત્યારે કારણ સામાન્ય રીતે ફોરવર્ડિંગ નીતિ, રિવર્સ-પાથ ફિલ્ટરિંગ અથવા ઓવરલેપિંગ સબનેટ હોય છે, ગુમ થયેલ રૂટ નહીં. વધુ વાંચતા પહેલાં પુષ્ટિ કરો કે તમે બેમાંથી કઈ દુનિયામાં છો:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

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

હોસ્ટ નેટવર્કિંગ એ કસોટી છે, ડિઝાઇન નહીં

કન્ટેનરને હોસ્ટ નેટવર્કિંગ સાથે ચલાવવું, જેને Docker હોસ્ટ નેટવર્ક નેમસ્પેસની ભાગીદારી તરીકે દસ્તાવેજીકૃત કરે છે, તેને ટનલ ઇન્ટરફેસ અને તેના રૂટ સીધા વારસામાં આપે છે. જો તે જ વિનંતી પછી સફળ થાય, તો રૂટ સિદ્ધાંત પુષ્ટિ થાય છે અને નિષ્ફળતા નેમસ્પેસ અલગતા છે, ઓળખપત્રો, DNS કે ઍક્સેસ નિયમ નહીં.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

તેને નિદાન તરીકે રાખો. હોસ્ટ નેટવર્કિંગ પોર્ટ પ્રકાશન અને કન્ટેનરથી તમે ઇચ્છતા મોટાભાગના અલગીકરણનો ત્યાગ કરે છે, અને Docker Desktop પર «host» એ વર્ચ્યુઅલ મશીન છે, ડેસ્કટોપ નહીં, તેથી તમે કયા હોસ્ટને સંબોધતા હતા તે ભૂલી જાઓ તો ત્યાંની સફળતા કે નિષ્ફળતા તમને ભ્રમિત કરી શકે છે.

tun ઉપકરણ અને તેની સાથે આવતા વિશેષાધિકારો

કન્ટેનરની અંદરના VPN ક્લાયન્ટને ટનલ ઉપકરણ અને તેને ગોઠવવાની પરવાનગી જોઈએ. સામાન્ય શોર્ટકટ --privileged છે, જે દરેક ઉપકરણ આપે છે અને આખા કન્ટેનરમાં સુરક્ષા નીતિ ઢીલી કરે છે. આ આ કાર્યની જરૂર કરતાં ઘણું વધારે છે, અને સમીક્ષામાં તેને ન્યાયી ઠેરવવું મુશ્કેલ છે.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

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

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

બ્રિજ NAT VPN જે સ્રોત જુએ છે તેને બદલે છે

ડિફોલ્ટ બ્રિજ સાથે કન્ટેનરનો બહાર જતો ટ્રાફિક હોસ્ટના સરનામામાં અનુવાદિત થાય છે. તેથી VPN પાછળ કોર્પોરેટ બાજુ કન્ટેનરના નહીં, હોસ્ટના ટનલ સરનામાને જુએ છે, સ્રોત પ્રમાણેના ઍક્સેસ નિયમો એવી રીતે વર્તે છે જાણે વિનંતી હોસ્ટે મોકલી હોય, અને બે કન્ટેનર VPN સર્વર માટે અભેદ્ય બની જાય છે.

macvlan અથવા ipvlan તેના બદલે કન્ટેનરને LAN સરનામું આપે છે, જે LAN શોધમાં મદદ કરે છે અને કન્ટેનરને સેગમેન્ટ પર સમકક્ષ જેવું દેખાડે છે. તે હોસ્ટના ટનલને સંપૂર્ણપણે ટાળે છે, તેથી આવું કન્ટેનર ફક્ત-VPN પ્રીફિક્સ સુધી પહોંચશે નહીં જ્યાં સુધી VPN તે LAN પરથી પણ સુલભ ન હોય.

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

DNS ડિમનને અનુસરે છે, ટનલને નહીં

કન્ટેનર શરૂ થાય ત્યારે તેની રિઝોલ્વર ગોઠવણી મેળવે છે, જે ડિમન અથવા ઇમેજમાંથી નકલ કરેલી હોય છે. VPN જોડાયા પછી ધકેલતા સરનામાં તે નકલ માટે ઘણા મોડા આવે છે, અને તેઓ કન્ટેનરમાં નહીં, હોસ્ટ રિઝોલ્વરમાં ધકેલાય છે.

સેવા માટે રિઝોલ્વર સ્પષ્ટ રીતે સેટ કરો, અથવા તેને ટનલ દ્વારા સુલભ આંતરિક રિઝોલ્વર તરફ નિર્દેશ કરો. જે કન્ટેનર ખાનગી નામને જાહેર સરનામામાં ઉકેલે છે તે સામાન્ય રીતે જાહેર રિઝોલ્વર વાપરે છે, તૂટેલા રૂટથી પીડાતું નથી, અને સુધારો compose ફાઇલ અથવા ડિમન ગોઠવણીમાં આવે છે.

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

ટિકિટ બંધ કરતા પહેલાં ચેકલિસ્ટ: ટનલની માલિકી ધરાવતું નેમસ્પેસ ઓળખો, હોસ્ટ નેટવર્કિંગથી માર્ગ સાબિત કરો, ફક્ત જરૂરી tun ઉપકરણ મેપ કરો, NAT પછીનું સ્રોત સરનામું યાદ રાખો, રિઝોલ્વર સ્પષ્ટ સેટ કરો અને પ્રતિ-કન્ટેનર બહાર જવાના સરનામાંને ફ્લેગ નહીં, સ્થાપત્ય નિર્ણય તરીકે ગણો.