macvlan કન્ટેનર VPN ક્લાયન્ટને જવાબ કેમ ન આપી શકે

Linux હોસ્ટની કલ્પના કરો જે VPN સમાપ્ત કરે છે અને સાથે જ macvlan નેટવર્ક પર કન્ટેનર ચલાવે છે. LAN 192.168.60.0/24 છે, કન્ટેનર પાસે 192.168.60.210 છે, અને VPN ક્લાયન્ટ 10.95.0.0/24 થી આવે છે. ક્લાયન્ટ સેવા સુધી પહોંચે છે, જવાબ ક્યારેય પાછો આવતો નથી, અને હોસ્ટ પરનો દરેક ફાયરવોલ નિયમ સાચો દેખાય છે. બે અલગ મર્યાદાઓ આ લક્ષણ ઉત્પન્ન કરે છે, અને એકને સુધારવાથી બીજી પોતાની જગ્યાએ રહે છે.

બે મર્યાદાઓ, એક લક્ષણ

પ્રથમ મર્યાદા અલગતા છે: Dockerનું macvlan ડ્રાઇવર કન્ટેનરને પેરેન્ટ ઇન્ટરફેસ દ્વારા પોતાના હોસ્ટ સાથે વાત કરવા દેતું નથી. હોસ્ટ સ્ટેક અને કન્ટેનર વચ્ચેના ટ્રાફિકનો કોઈ માર્ગ નથી, હોસ્ટ પરના રૂટ કેવી રીતે લખાયા હોય તે ધ્યાનમાં ન લેતા.

બીજી મર્યાદા પરત માર્ગ છે. કન્ટેનરનું ડિફોલ્ટ ગેટવે સામાન્ય રીતે LAN રાઉટર હોય છે, તેથી VPN ક્લાયન્ટને સંબોધિત જવાબ તે રાઉટર દ્વારા બહાર જાય છે. જો રાઉટર પાસે VPN પૂલ તરફ પાછા જવાનો કોઈ રૂટ ન હોય, તો જવાબ વચ્ચે ક્યાંક ફેંકી દેવામાં આવે છે.

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

હોસ્ટ બાજુનું શિમ સાંકડી રીતે બનાવો

હોસ્ટ પર બીજું macvlan ઇન્ટરફેસ, જે તે જ પેરેન્ટ સાથે બ્રિજ મોડમાં જોડાયેલું છે, તે હોસ્ટ સ્ટેકને તે LAN સેગમેન્ટ પર પોતાની ઓળખ આપે છે. તેના માટે DHCP પૂલની બહાર અને કન્ટેનર શ્રેણીની બહાર સરનામું અનામત રાખો, અને ફક્ત કન્ટેનરને તેનાથી પસાર કરો.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

પ્રથમ આદેશ ઇન્ટરફેસને બ્રિજ મોડમાં બનાવે છે, જે આ ડ્રાઇવર માટે દસ્તાવેજી ડિફોલ્ટ છે અને હોસ્ટ-કન્ટેનર ટ્રાફિક માટે તમે જે મોડ ઇચ્છો છો તે છે. બીજો /32 સોંપે છે જેથી સરનામું LAN પ્રીફિક્સ સાથે અથડાય નહીં, અને ચોથો ફક્ત કન્ટેનરનું સરનામું શિમ દ્વારા મોકલે છે.

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

આ આદેશો ચાલુ હોસ્ટ પર નેટવર્ક સેટિંગ બદલે છે. ઉપકરણ અથવા સંચાલિત પ્લેટફોર્મ પર તે પ્લેટફોર્મની સમર્થિત ગોઠવણી પદ્ધતિ વાપરો, કારણ કે root-shell માં કરેલો ઇન્ટરેક્ટિવ ફેરફાર અપગ્રેડ પછી ટકી ન પણ શકે.

સ્રોત કેવી રીતે સચવાય તે નક્કી કરો

શિમ હાજર હોય ત્યારે કન્ટેનર હોસ્ટ સુધી પહોંચી શકે છે, અને પ્રશ્ન એ થાય છે કે જવાબ કયું સ્રોત સરનામું ધરાવે છે. મૂળ VPN સ્રોત સાચવવો વધુ સ્વચ્છ મોડેલ છે: કન્ટેનર ક્લાયન્ટનું સાચું સરનામું જુએ છે, અને સેવાના લોગ અને ઍક્સેસ નિયમો તેનો ઉપયોગ કરી શકે છે.

તે કામ કરે તે માટે કન્ટેનરની નેટવર્ક ગોઠવણીએ આ માર્ગ માટે 10.95.0.0/24 નો ટ્રાફિક 192.168.60.250 પર તેના ગેટવે તરીકે મોકલવો જોઈએ. આ કન્ટેનરની પોતાની ગોઠવણીની અંદર સમર્થિત રૂટ અથવા ગેટવે સેટિંગ છે, હોસ્ટ બાજુની યુક્તિ નથી. સેટિંગ લાગુ પડ્યું છે એમ ધારવાને બદલે કન્ટેનરની અંદરથી તેની ખાતરી કરો. જે ડિફોલ્ટ ગેટવે હજી LAN રાઉટર તરફ દોરે છે તે જવાબોને તે જ ખાડામાં મોકલતું રહેશે.

જો મંજૂર રચના તેના બદલે VPN સ્રોતો છુપાવે છે, તો અનુવાદને સાંકડી રીતે મર્યાદિત કરો: વાસ્તવિક VPN પૂલ, આઉટગોઇંગ ઇન્ટરફેસ તરીકે શિમ, અને ચોક્કસ કન્ટેનર અને સેવા.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

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

ક્લાયન્ટથી ચકાસો, હોસ્ટથી નહીં

હોસ્ટ પોતે શિમના સરનામા સાથે બંધાયેલી વિનંતી મોકલે તે સાબિત કરે છે કે શિમ કન્ટેનર સુધી પહોંચી શકે છે. તે સાબિત કરતું નથી કે કન્ટેનર સચવાયેલા 10.95.0.x સ્રોત પર ટ્રાફિક પાછો મોકલી શકે છે, કારણ કે તે પરીક્ષણમાં સ્રોત સરનામું શિમનું પોતાનું છે.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

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

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

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