VPN કન્ટેનરમાં DNAT: INPUT નહીં, ફોરવર્ડિંગ

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

અનુવાદ પછી પેકેટને અનુસરો

10.90.0.0/24 નો ક્લાયન્ટ પૂલ અને 10.90.0.1 નું ટનલ સરનામું લો. એક બ્રિજ પર બે કન્ટેનર છે: 192.0.2.2 VPN ચલાવે છે અને 192.0.2.3 એપ્લિકેશન ચલાવે છે. ક્લાયન્ટ 10.90.0.1:8080 સાથે જોડાય છે, અને VPN કન્ટેનરના નેમસ્પેસનો DNAT નિયમ તેને એપ્લિકેશનના વાસ્તવિક સરનામા અને પોર્ટમાં ફરીથી લખે છે. પછી રૂટ પેકેટને બ્રિજ પરથી મોકલે છે. આ સરનામાં ઉદાહરણરૂપ છે, ડિપ્લોયમેન્ટ રેસિપી નથી.

એપ્લિકેશન ખરેખર જે પોર્ટ પર સાંભળે છે તે હોસ્ટ પર પ્રકાશિત કોઈપણ પોર્ટથી અલગ હોઈ શકે છે. બંને સંખ્યા મળે છે એમ ધારવાને બદલે કન્ટેનરની અંદરનો શ્રોતા વાંચો.

પરવાનગી ફોરવર્ડ માર્ગ પર રહે છે

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

વ્યાપ સાંકડો રાખો: એક સ્રોત શ્રેણી, એક ગંતવ્ય, એક સેવા. છૂટછાટવાળો ફોરવર્ડિંગ નિયમ લખવો સરળ છે અને પછી સમર્થન કરવું ઘણું મુશ્કેલ.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker ની ચેઇન તમારા કન્ટેનરની ચેઇન નથી

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

Docker ફાયરવોલ સંદર્ભ તે ચેઇન અને DNAT પછીનો મેળ વર્ણવે છે. Docker નું ફાયરવોલ સંચાલન બંધ કરીને અથવા દરેક ચેઇન છૂટછાટવાળી બનાવીને ખૂટતી સ્વીકૃતિ સુધારશો નહીં, કારણ કે તે તમે વાપરવા માંગતી સીમા દૂર કરે છે.

પરત માર્ગને સભાન પસંદગી બનાવો

જો સ્રોત સરનામું સચવાય છે, તો એપ્લિકેશન 10.90.0.x જુએ છે અને જવાબો VPN કન્ટેનર દ્વારા પાછા મોકલવા પડે છે. નહીં તો તેનું સામાન્ય Docker ગેટવે તેમને હોસ્ટ પર મોકલશે, જેની પાસે ટનલ નથી. વિકલ્પ એ VPN કન્ટેનર પર સાંકડી સ્રોત અનુવાદ છે, જે જવાબ સરળ બનાવે છે પણ એપ્લિકેશનથી ક્લાયન્ટ છુપાવે છે. સભાનપણે પસંદ કરો અને તમે કયો પસંદ કર્યો તે લખો.

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

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