Docker કન્ટેનરનો ટ્રાફિક હોસ્ટ VPNને બાયપાસ કરે છે: કેવી રીતે તપાસવું
હોસ્ટ VPN ફક્ત હોસ્ટ નેમસ્પેસ આવરી લે છે. આ તપાસો દ્વારા જાણો કે બ્રિજ કન્ટેનરનો ટ્રાફિક ટનલમાં જાય છે કે સીધો બહાર નીકળે છે.
તમારો હોસ્ટ બ્રાઉઝર VPN એક્ઝિટ સરનામું બતાવે છે, કન્ટેનર તમારું ઘરનું કનેક્શન જણાવે છે, અને કોઈ તેને લીક કહે છે. કંઈ લીક થયું નથી. હોસ્ટ ટનલ એ ઇન્ટરફેસ, રૂટ અને નિયમોનો સમૂહ છે જે હોસ્ટ નેટવર્ક નેમસ્પેસનો છે, અને બ્રિજ પરનું કન્ટેનર પોતાના ડિફોલ્ટ રૂટ સાથેનું બીજું નેમસ્પેસ છે. હું એવા Compose સ્ટેક પર બેઠો છું જ્યાં VPN ક્લાયન્ટ અઠવાડિયાઓથી જોડાયેલો હતો અને એક પણ કન્ટેનર પેકેટ ક્યારેય તેમાં દાખલ થયું નહોતું.
ટ્રે આઇકન પહેલાં નેમસ્પેસ તપાસો
નેમસ્પેસ એ આખી દલીલ છે. જ્યારે Docker બ્રિજ નેટવર્ક પર કન્ટેનર શરૂ કરે છે, ત્યારે તે નેટવર્ક નેમસ્પેસ બનાવે છે, veth જોડીનો એક છેડો તેની અંદર જોડે છે, અને તે નેમસ્પેસને સરનામું અને ડિફોલ્ટ રૂટ આપે છે. ટનલ ઇન્ટરફેસ, તેને ગમે તે નામે ઓળખવામાં આવે, હોસ્ટ નેમસ્પેસમાં રહે છે. કન્ટેનરની અંદરનો ટ્રાફિક તેને જોઈ શકતો નથી, અને બહારથી કોઈ ક્લાયન્ટ સેટિંગ તેને બદલતું નથી.
બે સમર્થિત પગલાં તમને અલગતામાંથી બહાર કાઢે છે. --network host કન્ટેનરને હોસ્ટ નેમસ્પેસની અંદર મૂકે છે, તેથી તે હોસ્ટના રૂટ અને તેથી ટનલ વારસામાં મેળવે છે. --network container:vpn બીજા કન્ટેનરનું નેમસ્પેસ વહેંચે છે, અને મોટાભાગની સાઇડકાર ડિઝાઇન આ રીતે વર્કલોડને VPN કન્ટેનર દ્વારા મોકલે છે. બંને સ્પષ્ટ પસંદગીઓ છે; સામાન્ય રીતે તેમાંથી ફક્ત એક જ તે વસ્તુ હોય છે જે ડિપ્લોય કરનાર વ્યક્તિનો ઇરાદો હતો.
હોસ્ટ મોડ મફત અપગ્રેડ નથી. કન્ટેનર પોતાનું સરનામું ધરાવવાનું બંધ કરે છે, પોર્ટ પ્રકાશન લાગુ થવાનું બંધ કરે છે, અને ત્યાં NET_ADMIN ધરાવતી પ્રક્રિયા હોસ્ટનું રાઉટિંગ ફરીથી લખી શકે છે. તેને સ્વીકારવું યોગ્ય નિર્ણય હોઈ શકે. તે પહેલેથી ચાલુ છે એમ ધારવું એ છે કેવી રીતે લોકો સાંજ એવી ટનલ ડિબગ કરવામાં પસાર કરે છે જે ક્યારેય માર્ગમાં નહોતી.
પેકેટને બ્રિજની બહાર અનુસરો
બ્રિજ કન્ટેનર તેનું પેકેટ તેના ડિફોલ્ટ ગેટવે પર મોકલે છે, જે હોસ્ટ પરનું બ્રિજ ઇન્ટરફેસ છે. પછી હોસ્ટ પેકેટને ફોરવર્ડ કરે છે અને ડિફોલ્ટ રૂપરેખાંકનમાં પેકેટ નીકળતા પહેલાં સ્રોત સરનામાને પોતાના સરનામામાં અનુવાદિત કરે છે. એ જ અનુવાદનું પગલું નીતિને શાંતિથી હરાવે છે.
જ્યારે પેકેટ ટનલના અંતિમ બિંદુ સુધી પહોંચે છે ત્યારે તે હોસ્ટનું સરનામું વહન કરે છે. કન્ટેનરના મૂળ સરનામા પર આધારિત કોઈપણ નિયમ, નીતિ-રૂટ કે સ્પ્લિટ-ટનલ નિર્ણય મેળ ખાવાનું બંધ કરે છે, અને જુદા જુદા એક્ઝિટ દ્વારા નીકળવાના બે કન્ટેનરને ફક્ત સ્રોત દ્વારા અલગ પાડી શકાતા નથી. જો તમને પ્રતિ-કન્ટેનર રાઉટિંગની જરૂર હોય, તો નિર્ણય અનુવાદ પહેલાં કે તમે નિયંત્રિત કરો છો તેવા નેમસ્પેસની અંદર થવો જોઈએ.
Docker આ નિયમો જાતે જાળવે છે, ડેમન જે ફાયરવોલ બેકએન્ડ સાથે રૂપરેખાંકિત કરવામાં આવ્યો હોય તેના દ્વારા. ફોરવર્ડ કરેલા ટ્રાફિક માટેના સમર્થિત હૂકની બહાર હાથે લખાયેલા નિયમો, DOCKER-USER, ડેમન ફરી શરૂ થાય કે હોસ્ટ અપગ્રેડ થાય ત્યારે ફરીથી ગોઠવાઈ શકે છે અથવા દૂર થઈ શકે છે. પેકેટ ફિલ્ટરિંગ પર Dockerનું દસ્તાવેજીકરણ સાંકળોનો ક્રમ બતાવે છે; વ્યવહારુ મુદ્દો એ છે કે દરેક નિયમને એક માલિક અને એક રીલોડ માર્ગની જરૂર છે જે તમે ખરેખર પરીક્ષણ કર્યો હોય.
બે સિસ્ટમને અલગથી પરીક્ષણ કરો
એક નેમસ્પેસનો પુરાવો બીજા વિશે કંઈ કહેતો નથી. VPN કન્ટેનરની અંદર ચલાવાયેલી વિનંતી સાબિત કરે છે કે ટનલ તે કન્ટેનર માટે કામ કરે છે. તે હોસ્ટ વિશેનો પુરાવો નથી, અને --network host કન્ટેનરમાંથી ચલાવાયેલો એ જ આદેશ બ્રિજ વિશેનો પુરાવો નથી.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'પછી પરીક્ષણને સમાન ઇમેજમાં નહીં, પરંતુ વાસ્તવિક એપ્લિકેશન કન્ટેનરની અંદર પુનરાવર્તિત કરો. એપમાં વધારાનો રૂટ, પ્રોક્સી પર્યાવરણ ચલ કે જુદો રિઝોલ્વર હોઈ શકે છે, અને તેમાંથી દરેક જવાબ બદલે છે. દર વખતે નામ-રિઝોલ્યુશન અને બીજું સરનામા કુટુંબ તપાસો: વપરાશકર્તા-વ્યાખ્યાયિત બ્રિજ પરના કન્ટેનર Dockerના બિલ્ટ-ઇન રિઝોલ્વર દ્વારા 127.0.0.11 પર રિઝોલ્વ થાય છે, અને બ્રિજ પરનો IPv6 ડિફોલ્ટ રૂટ ટ્રાફિકને બહાર લઈ જઈ શકે છે જ્યારે તમે ફક્ત IPv4 ટનલનું પરીક્ષણ કરવામાં વ્યસ્ત હો.
ઓળખપત્રોને સ્પર્શ કરતા પહેલાં પેટર્ન વાંચો
જ્યારે હોસ્ટ કામ કરે છે અને કન્ટેનર નહીં, ત્યારે કારણ લગભગ હંમેશા માળખાકીય હોય છે, અને કી ફેરવવી કે ક્લાયન્ટ ફરી ઇન્સ્ટોલ કરવો એ બપોર બગાડે છે. પહેલાં લક્ષણને ગોઠવો અને સુધારો સામાન્ય રીતે પોતાનું નામ આપી દે છે.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
ઓવરલેપ પંક્તિ પોતાનું વાક્ય લાયક છે. જે VPN પ્રોફાઇલ 172.17.0.0/16 માટે, અથવા એવા 10.0.0.0/8 માટે રૂટ ધકેલે છે જેમાં તમારો બ્રિજ પ્રીફિક્સ યોગાનુયોગ આવી જાય છે, તે ટનલને કન્ટેનર સબનેટનો દાવો કરાવે છે, અને અનુવાદિત સરનામાંઓને જતા જવાબો ખોટી દિશામાં જશે અથવા અદૃશ્ય થશે. Docker નેટવર્કને ફરીથી ક્રમાંકિત કરવું સામાન્ય રીતે અપવાદો જમા કરવા કરતાં વધુ સ્વચ્છ છે.
કવરેજને સ્પષ્ટ કરો, પછી તેને જાણી જોઈને તોડો
બે ડિઝાઇન સમીક્ષામાં ટકી રહે છે. VPN કન્ટેનરનું નેમસ્પેસ વહેંચો અને દરેક આવરી લેવાયેલ વર્કલોડ એક રીસ્ટાર્ટ સીમા સાથે એક ટનલ વાપરે છે, જે સરળ છે જ્યાં સુધી કોઈ એક સેવાને જુદું એક્ઝિટ કે પોતાનો DNS માર્ગ જોઈએ નહીં. અથવા કન્ટેનર નેટવર્કને હોસ્ટ પરના VPN ગેટવે તરફ રૂટ કરો: ફોરવર્ડિંગ સક્ષમ, બ્રિજ પ્રીફિક્સ ટનલ તરફ નિર્દેશિત, પરત ટ્રાફિક સ્પષ્ટ રીતે સંભાળ્યો. તે નેટવર્ક દીઠ નિયંત્રણ ખરીદે છે અને ડેમન તથા ક્લાયન્ટ અપગ્રેડ દરમિયાન જાળવવાના નિયમોનો સમૂહ તમને ખર્ચે છે.
ગમે તે રીતે, મહત્વનું પરીક્ષણ નિષ્ફળતાનો કિસ્સો છે. કન્ટેનરની વિનંતી ઉડાનમાં હોય ત્યારે ટનલ બંધ કરો અને જુઓ પેકેટ ક્યાં જાય છે. જો તે સીધા માર્ગ પર પાછું આવે, તો કવરેજ ક્યારેય લાગુ થયું જ નહોતું, કારણ કે ક્લાયન્ટનું kill switch ક્લાયન્ટના પોતાના ટ્રાફિકને નિયંત્રિત કરે છે, બ્રિજમાંથી ફોરવર્ડ થયેલા પેકેટને નહીં. પછી ડેમન અને હોસ્ટ ફરી શરૂ કરો અને પરિણામ બીજી વાર પુષ્ટિ કરો; તે જ ક્ષણ છે જ્યારે હાથે લખાયેલા નિયમો અદૃશ્ય થાય છે.
તેને પૂર્ણ કહેતા પહેલાં ચાર વસ્તુઓની પુષ્ટિ કરો: ટનલ ઇન્ટરફેસ ટ્રાફિક જેવા જ નેમસ્પેસમાં છે, કન્ટેનર પરીક્ષણ વાસ્તવિક કન્ટેનરની અંદર ચાલ્યું, નામ-રિઝોલ્યુશન અને બંને સરનામા કુટુંબો તપાસાયા, અને ટનલ-નિષ્ફળતા પરીક્ષણ હજી પણ બંધ રીતે નિષ્ફળ થાય છે. પછી ફાયરવોલ બેકએન્ડ, ક્લાયન્ટ સંસ્કરણ અને દરેક નિયમનો માલિક લખો. તે જ રેકોર્ડ અટકાવે છે કે આગલું અપગ્રેડ જૂની ધારણાઓનું અપ્રલેખિત મિશ્રણ છોડી ન જાય.