Windows કન્ટેનર અને VPN: સ્થાનિક નેટવર્ક કેમ તૂટે છે
Windows કન્ટેનર હોસ્ટના રૂટ ટેબલનો ઉપયોગ કરે છે, તેથી સ્થાનિક સબનેટને બ્લોક કરતું VPN કન્ટેનરનું પ્રીફિક્સ પણ સાથે લઈ જાય છે. Linux મોડ બીજો રસ્તો લે છે.
એક લેપટોપ પર, એક VPN ક્લાયન્ટ જોડાયેલો હોય ત્યારે, Linux કન્ટેનર એકબીજા સાથે વાત કરવાનું ચાલુ રાખે છે અને Windows કન્ટેનર અટકી જાય છે. ચલ ઇમેજ નથી; પેકેટ હોસ્ટમાં જે માર્ગે જાય છે તે ચલ છે. ડિફોલ્ટ નેટવર્ક પરના Windows કન્ટેનર હોસ્ટનું રૂટ ટેબલ અને અનુવાદ ઉધાર લે છે, તેથી હોસ્ટના રાઉટિંગને બદલતી નીતિ તેમને પણ બદલે છે. કંઈપણ ફરીથી ઇન્સ્ટોલ કરતા પહેલા રૂટ લુકઅપ સાથે તેની પુષ્ટિ કરો.
Windows કન્ટેનરના પેકેટ હોસ્ટમાં ક્યાં પ્રવેશે છે
ડિફોલ્ટ nat નેટવર્ક પરનું કન્ટેનર Host Networking Service ના પ્રીફિક્સમાંથી સરનામું મેળવે છે, સામાન્ય રીતે 172.16.0.0/12 ની અંદર ક્યાંક, અને વર્ચ્યુઅલ એડેપ્ટર દ્વારા હોસ્ટ સુધી પહોંચે છે. હોસ્ટ તે પ્રીફિક્સની રૂટ ધરાવે છે અને ટ્રાફિકને જે એડેપ્ટર હાલ સક્રિય છે તેની તરફ અનુવાદિત કરે છે. તે માર્ગની વચ્ચે અલગ વર્ચ્યુઅલ મશીન નથી.
આ ડિઝાઇન જ નિષ્ફળતાને યાંત્રિક બનાવે છે. જ્યારે કન્ટેનર પેકેટ મોકલે છે, ત્યારે હોસ્ટ કન્ટેનર પ્રીફિક્સ માટે રૂટ લુકઅપ કરે છે. કઈ રૂટ જીતે છે ત્યાં જ પેકેટ જાય છે, અને કન્ટેનરને તેમાં કોઈ મત નથી.
VPN ક્લાયન્ટ તે માર્ગ પર શું બદલે છે
કોર્પોરેટ ક્લાયન્ટ ઘણી વખત રૂટનો વિશાળ સમૂહ અને એક ફિલ્ટર ઇન્સ્ટોલ કરે છે જે ટનલ ચાલુ હોય ત્યારે સ્થાનિક સબનેટનો ઍક્સેસ નકારે છે. હેતુ સંરક્ષણાત્મક છે: સમાધાન થયેલું સ્થાનિક નેટવર્ક સુરક્ષિત મશીન સુધી ન પહોંચવું જોઈએ. આડઅસર એ છે કે હોસ્ટની રૂટ કન્ટેનર પ્રીફિક્સ સુધીની હવે સ્થાનિક NAT નેટવર્ક નથી.
તેના બદલે લુકઅપ ટનલ સાથે મેળ ખાય છે અને પેકેટ ગેટવેને સોંપવામાં આવે છે, જેણે તે કન્ટેનર સરનામું ક્યારેય સાંભળ્યું નથી. Ping નિષ્ફળ જાય છે, એપ્લિકેશન સમય પૂરો થાય છે, અને VPN આઇકન ચમકતું હોય ત્યારે કન્ટેનર તૂટેલું દેખાય છે. જોડાયેલા હોય ત્યારે હોસ્ટનું ટેબલ જુઓ અને હરીફ રૂટ દેખાય છે.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Linux કન્ટેનર અલગ વર્તન કેમ કરે છે
Linux એન્જિન કન્ટેનરને હલકી વર્ચ્યુઅલ મશીનની અંદર ચલાવે છે, અને તે મશીનમાંથી બહાર જતા જોડાણો કન્ટેનર વતી હોસ્ટ બાજુનો પ્રોક્સી ખોલે છે. સોકેટ હોસ્ટ શરૂ કરે છે, તેથી કન્ટેનર પ્રીફિક્સ વિશેનો VPN નિયમ તેના પર એ જ રીતે લાગુ પડતો નથી, અને કાર્યભાર નેટવર્ક સુધી પહોંચવાનું ચાલુ રાખે છે.
એ તફાવત એ પણ સમજાવે છે કે Linux રેસિપીઓ કેમ સ્થાનાંતરિત થતી નથી. જે Linux કન્ટેનરને પોતાની ટનલની જરૂર હોય તેને TUN ઉપકરણ અને NET_ADMIN ક્ષમતા આપવામાં આવે છે. Windows કન્ટેનર કોઈ ઇન્ટરફેસને ઉપકરણ તરીકે આગળ ધરતું નથી, તેથી તે પેટર્નનું તે બાજુ કોઈ સમકક્ષ નથી.
રૂટ સાબિત કરો, પછી ડિઝાઇન પસંદ કરો
પુરાવા હોસ્ટ પાસેથી એકઠા કરો, કન્ટેનર પાસેથી નહીં, કારણ કે લુકઅપ હોસ્ટ કરે છે:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"VPN જોડાય તે પહેલાં એક વાર અને પછી એક વાર રૂટ આઉટપુટ ચલાવો. જો બીજા આઉટપુટમાં કન્ટેનર પ્રીફિક્સ ટનલ એડેપ્ટર તરફ ઇશારો કરે, તો નિદાન પૂર્ણ છે અને કન્ટેનર ફરીથી શરૂ કરવાથી મદદ મળશે નહીં.
પહેલો વિકલ્પ નીતિનો નિર્ણય છે: નેટવર્કના માલિકને પૂછો કે આ ઉપકરણ માટે સ્થાનિક LAN ઍક્સેસની મંજૂરી આપી શકાય છે કે નહીં. ઘણા કોર્પોરેટ ક્લાયન્ટ તેને સેટિંગ તરીકે આપે છે, પરંતુ તે જાણી જોઈને કરેલી સીમાને નબળી બનાવે છે. તેને માલિક અને સમીક્ષા તારીખ સાથે દસ્તાવેજીકૃત અપવાદ તરીકે માંગો. દરેક ઉપકરણ માટેનું ટોગલ જેની પાસે કોઈ પાછું ફરતું નથી તે જ રીતે સંરક્ષણાત્મક નીતિ ચૂપચાપ અદૃશ્ય થાય છે.
જ્યાં નીતિ ટકવી જોઈએ ત્યાં રૂટ સાથે લડવાને બદલે કાર્યભાર ખસેડો. સ્પષ્ટ સબનેટ અને ગેટવે સાથેનું પારદર્શક નેટવર્ક કન્ટેનરને સ્થાનિક લિંક પર મૂકે છે, Linux કાર્યભાર VM પ્રોક્સી પાછળ ચાલે છે, અને પોતાના ક્લાયન્ટ સાથેનું અલગ વર્ચ્યુઅલ મશીન પોતાની નીતિ જાળવી રાખે છે. એક જાણી જોઈને પસંદ કરો અને કન્ટેનરની અંદરથી તેની પરીક્ષા કરો, કારણ કે વપરાશકર્તાની વિનંતી ત્યાં જ ઉદ્ભવે છે.