VPN પર Docker કન્ટેનર પહોંચન બહાર? સબનેટની સરખામણી કરો
Docker એવું સબનેટ આપે છે જે VPN પણ માગે છે. બે સરનામા યોજનાઓની સરખામણી કરો, પછી એવો સુધારો પસંદ કરો જે ફરી કનેક્ટ થવા પર ટકી રહે.
કન્ટેનર ઓફિસ LAN પર જવાબ આપે છે, અને કંપનીનું VPN કનેક્ટ થાય તે ક્ષણે જ જવાબ આપવાનું બંધ કરે છે. કન્ટેનરમાં કંઈ બદલાયું નથી: કોઈ રીસ્ટાર્ટ નહીં, ઇમેજ અપડેટ નહીં, કન્ફિગમાં ફેરફાર નહીં. બદલાયું છે હોસ્ટનું રાઉટિંગ કોષ્ટક, જ્યાં ટનલે ઉમેરેલો રૂટ હવે Dockerે આપેલા સરનામાને આવરી લે છે. સબનેટ સંપાદિત કરવા કે VPN મુક્તિ માગવા પહેલાં બંને સરનામા યોજનાઓ સાથે સાથે મૂકો, કારણ કે સુધારાઓ ઘણો અલગ સમય લે છે.
કન્ફિગ બદલતા પહેલાં રૂટ વાંચો
Dockerે ખરેખર બનાવેલી નેટવર્કથી શરૂ કરો. IPAM બ્લોક એ સરનામા યોજના છે, અને સબનેટ એ લાઇન છે જે મહત્વની છે:
docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]Compose દરેક નવા પ્રોજેક્ટને ડિફૉલ્ટ રૂપે /16 ફાળવે છે, તેથી બે સેવાઓ 65,536 સરનામાંના શ્રેણીમાં બેસી શકે છે. આ પહોળાઈ જ ઓવરલેપ સામાન્ય હોવાનું કારણ છે: અવ્યવસ્થિત રીતે પસંદ કરેલું /16 ટનલ દ્વારા પહોંચતી સાઇટને ગળી જવા પૂરતું મોટું છે, અને ટનલ ઉપર આવે ત્યાં સુધી કોઈ ધ્યાન આપતું નથી.
પછી એક કન્ટેનર સરનામા માટે રૂટ પસંદગીની સરખામણી કરો, એક વાર ટનલ બંધ અને એક વાર ચાલુ સાથે:
ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1જવાબના બે આકાર જુદી જગ્યાએ લઈ જાય છે. જો આઉટપુટ tun0, wg0 અથવા બીજા ટનલ ઉપકરણનું નામ આપે, તો VPN પ્રીફિક્સ બ્રિજ રૂટ જેટલું ઓછામાં ઓછું વિશિષ્ટ છે અને પેકેટ ક્યારેય કન્ટેનર સુધી પહોંચતું નથી. જો તે હજી પણ બ્રિજનું નામ આપે, તો હોસ્ટ કન્ટેનર સુધી પહોંચી શકે છે, અને તમારી ખામી ફિલ્ટરિંગ, DNS અથવા ફક્ત એક દિશામાં નિષ્ફળ જતો પરત માર્ગ છે.
શા માટે /16 અથડામણ સહેલી છે
Docker ખાનગી પૂલમાંથી બ્રિજ નેટવર્ક લે છે, અને ડિફૉલ્ટ પૂલ 172.16.0.0/12 બ્લોકમાંથી /16 ટુકડાઓમાં આવે છે. કોર્પોરેટ નેટવર્ક ઘણી વાર એ જ ખાનગી જગ્યા વાપરે છે, અને રિમોટ-એક્સેસ VPN એ પ્રીફિક્સને દરેક કનેક્ટ થતા ક્લાયન્ટ સુધી ધકેલે છે. જ્યારે બંને પક્ષ માને છે કે 172.18.0.0/16 તેમની પાસે છે, ત્યારે એક રાઉટિંગ કોષ્ટક બે વિરોધાભાસી દાવા રાખે છે.
વિજેતા પ્રીફિક્સની લંબાઈ નક્કી કરે છે, રૂટ કયા ક્રમમાં દેખાય છે તે નહીં. જે ટનલ 10.0.0.0/8 ધકેલે છે તે 172.18.0.0/16 બ્રિજ રૂટને હરાવતું નથી, કારણ કે /8 ઓછું વિશિષ્ટ છે. જે ટનલ 172.18.0.0/16, અથવા 172.18.5.0/24 તેની અંદર ધકેલે છે, તે હરાવે છે. તેથી જ એક લેપટોપ ઓફિસ નેટવર્ક પર કામ કરે છે અને હોટેલ Wi-Fi પર એ જ VPN સાથે નિષ્ફળ જાય છે: ક્લાયન્ટને જુદા જુદા પ્રીફિક્સ મળે છે.
એ જ કોષ્ટક બીજી દિશાને પણ નિયંત્રિત કરે છે. જે કન્ટેનરને 10.8.4.20 પર આંતરિક હોસ્ટની જરૂર છે તે પેકેટને પોતાના બ્રિજ ગેટવે પર મોકલે છે, અને પછી હોસ્ટ તેને ટનલમાં રૂટ કરે છે. આ માર્ગ સામાન્ય રીતે કામ કરે છે કારણ કે હોસ્ટ NAT કરે છે, પણ તે ત્યારે નિષ્ફળ જાય છે જ્યારે કોર્પોરેટ બાજુ ફક્ત લેપટોપનું VPN સરનામું સ્વીકારે છે, અથવા જ્યારે રિવર્સ-પાથ ફિલ્ટરિંગ અસમમિત જવાબ કાઢી નાખે છે.
ત્રણ સુધારાઓની સરખામણી કરો
બહાર નીકળવાના ફક્ત ત્રણ રસ્તા છે, અને તે એમાં જુદા પડે છે કે કોને મંજૂરી આપવી પડે અને એક લાગુ કરતી વખતે શું તૂટે છે.
| Repair | Who owns it | What it costs |
|---|---|---|
| Renumber the container network | You | Recreates the network, restarts services, invalidates literal addresses in configs and scripts |
| Exclude your range from the tunnel | Network team | Changes what every laptop sees, needs a change request and a client profile update |
| Reach the service through a published port | You and the client | One port only, no direct container-to-container routing across the tunnel |
રીનંબરિંગ એ એકમાત્ર સુધારો છે જે તમે ટિકિટ વિના પૂરો કરી શકો છો, અને તેથી જ મોટાભાગના લેખ ત્યાં જ અટકે છે. નવા પ્રોજેક્ટમાં તે સસ્તું છે અને એકવાર માઇગ્રેશન ટૂલ કે સંગ્રહિત કનેક્શન સ્ટ્રિંગ શાબ્દિક સરનામા તરફ ઇશારો કરે ત્યારે મોંઘું છે. YAML સંપાદિત કરતા પહેલાં એ સંદર્ભોની ગણતરી કરો, પછી નહીં.
ટનલમાંથી મુક્તિ એ સૌથી સ્વચ્છ જવાબ છે જ્યારે ઓવરલેપ એવા શ્રેણીમાં હોય જે તમારી કંપની ખરેખર ધરાવે છે. તે સૌથી ધીમું પણ છે, અને જે કોન્ટ્રાક્ટર ક્લાયન્ટ પ્રોફાઇલ બદલી શકતું નથી તેના માટે નકામું છે. પ્રકાશિત પોર્ટ કે નાનું રિવર્સ પ્રોક્સી દલીલ ટાળે છે: ક્લાયન્ટ એવા સરનામા સાથે વાત કરે છે જે ટનલ પહેલેથી જ યોગ્ય રીતે રૂટ કરે છે, અને ફક્ત એ પોર્ટ સુધી પહોંચી શકાય તેવું હોવું જોઈએ.
ઇરાદાપૂર્વક શ્રેણી નિશ્ચિત કરો
એક પ્રોજેક્ટ માટે, compose ફાઇલમાં સબનેટ ઘોષિત કરો જેથી પ્રોજેક્ટ શેર કરેલા પૂલમાંથી લેવાનું બંધ કરે:
networks:
default:
ipam:
config:
- subnet: 10.201.7.0/24એ શ્રેણી તમારી ટીમ રાખે છે તે રજિસ્ટરમાંથી લો, શોધતી વખતે મળેલા ઉદાહરણમાંથી નહીં. VPN ધકેલે છે તે પ્રીફિક્સ, લોકો જે ઘરના LANમાંથી કામ કરે છે અને એ જ હોસ્ટ પરની બીજી કન્ટેનર નેટવર્ક સામે તેને ચકાસો. પછી પુનઃનિર્માણની યોજના કરો, કારણ કે હાલનું નેટવર્ક તેનું જૂનું સબનેટ રાખે છે: docker compose down, પછી up -d. docker network rm એન્ડપોઇન્ટ જોડાયેલા હોય ત્યાં સુધી ના પાડે છે, અને ફાઇલમાંની કોઈપણ ipv4_address એન્ટ્રી નવા શ્રેણીની અંદર આવવી જોઈએ.
Docker પોતે બનાવે છે તે નેટવર્ક માટે, /etc/docker/daemon.json માં ડિમન પૂલ સેટ કરો:
{
"default-address-pools": [
{ "base": "10.201.0.0/16", "size": 24 },
{ "base": "10.202.0.0/16", "size": 24 }
]
}પૂલ ડિમન ફરી શરૂ થયા પછી બનેલા નેટવર્ક પર લાગુ પડે છે, અને પહેલેથી હાજર બ્રિજ તેમના સરનામા રાખે છે. તે અનુકૂળ છે અને ભૂલવું સહેલું છે, તેથી જૂના પ્રોજેક્ટને ત્યાં સુધી હજી ઓવરલેપ થતો ગણો જ્યાં સુધી કોઈ તેનું નેટવર્ક ફરી ન બનાવે. Dockerનું એન્જિન નેટવર્કિંગ દસ્તાવેજીકરણ ફાળવણીના નિયમો વર્ણવે છે, જો સમીક્ષામાં પૂલનો બચાવ કરવો પડે.
Linux બ્રિજ અને Docker Desktop અલગ રીતે નિષ્ફળ જાય છે
Linux હોસ્ટ પર, કન્ટેનર હોસ્ટના નામ જગ્યાના બ્રિજ પર બેસે છે. એક કોષ્ટક બધું નક્કી કરે છે, તેથી ઉપરની સરખામણી આખી વાર્તા છે: બ્રિજ રૂટ વાંચો, ટનલ રૂટ વાંચો, અને જુઓ કે વાસ્તવિક કન્ટેનર સરનામા માટે કયું જીતે છે.
Docker Desktop કન્ટેનરને પોતાનું NAT ધરાવતા VM પાછળ મૂકે છે. હોસ્ટને કન્ટેનર સરનામા સુધી કોઈ રૂટ જ નથી; તે સેવા સુધી પ્રકાશિત પોર્ટ દ્વારા પહોંચે છે, જે સામાન્ય રીતે 127.0.0.1 સાથે બંધાયેલો હોય છે. તેથી VPN ક્લાયન્ટ કોઈપણ સબનેટ ઓવરલેપ વિના સેવા તોડી શકે છે, કાં તો VMના આંતરિક શ્રેણી માટે રૂટ સ્થાપિત કરીને, અથવા ટનલ કનેક્ટ હોય ત્યારે loopback ટ્રાફિક અવરોધીને. જો હોસ્ટ પર ip route get કન્ટેનર સરનામા માટે કોઈ રૂટ ન હોવાનું જણાવે, તો તે અપેક્ષિત છે, ખામી નહીં.
વ્યવહારુ પરિણામ એ છે કે તમે પહેલાં ક્યાં જુઓ છો. Linux પર, રાઉટિંગ કોષ્ટકથી શરૂ કરો. Desktop પર, પ્રકાશિત પોર્ટ અને VPN ક્લાયન્ટના ફાયરવોલ નિયમોથી શરૂ કરો, પછી તપાસો કે VMનું આંતરિક સબનેટ ટનલ ધકેલે છે તેવા કોઈની સાથે અથડાય છે કે નહીં.
ટનલ ચાલુ રાખીને ચકાસો
સુધરી ગયું કહેવા પહેલાં VPN બે વાર ફરી કનેક્ટ કરો, કારણ કે જે પ્રોફાઇલ કનેક્શન વખતે રૂટ ધકેલે છે અને ડિસ્કનેક્ટ વખતે પાછા ખેંચે છે તે પહેલી કોશિશ પછી સાચું લાગી શકે છે. પછી ક્લાયન્ટ ખરેખર ચલાવે છે તે ચકાસણીઓ ચલાવો:
ip route getહોસ્ટથી, કન્ટેનરના વાસ્તવિક સરનામાનો ઉપયોગ કરીને.- બીજા કન્ટેનર તરફથી વિનંતી, સેવા પોતે સ્વસ્થ છે તે સાબિત કરવા.
curl -sv http://127.0.0.1:8080/ટનલ ચાલુ હોય ત્યારે ક્લાયન્ટથી, પછીtraceroute -nLANમાંની મશીનથી કન્ટેનર સરનામા તરફ.sysctl net.ipv4.conf.all.rp_filterજો વિનંતી હોસ્ટ સુધી પહોંચે પણ જવાબ અદૃશ્ય થાય.
અંતે, પસંદ કરેલી શ્રેણીને એ જ રજિસ્ટરમાં લખો જેમાંથી તમે તે પસંદ કરી હતી, તારીખ અને તેની માલિકી ધરાવતા પ્રોજેક્ટ સાથે. આગામી ઓવરલેપ એવા પ્રોજેક્ટમાંથી આવશે જે કોઈએ દસ્તાવેજ કર્યું નથી, અને એકમાત્ર બચાવ એ છે કે શ્રેણી ઇરાદાપૂર્વક અનામત રાખવામાં આવી હતી, અવ્યવસ્થિત રીતે ખેંચાઈ નહોતી.