Docker પોર્ટ પ્રકાશન અને VPN સ્રોત: બે મેળ જે તમે ચૂકો છો

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

દંતકથા: VPN સર્વરને મંજૂર કરો અને કામ પૂરું

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

તેથી VPN સર્વર IP વાક્યાંશ ધારણાનું વર્ણન કરે છે, અવલોકનનું નહીં. જ્યાં સુધી તમે ન જાણો કે બેમાંથી કઈ રચના તમારી સામે છે, નિયમ અનુમાન છે.

સ્રોત: ક્લાયન્ટ પૂલ કે અનુવાદિત ગેટવે

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

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

પોર્ટ: DNAT એ મેળ ખાતો આંકડો બદલે છે

Docker iptables સાથેના સામાન્ય Linux બ્રિજ પ્રકાશનમાં, 8443 થી કન્ટેનર પોર્ટ 443 સુધીનું યજમાન મેપિંગ ફોરવર્ડિંગ ફિલ્ટર ચાલે તે પહેલા અનુવાદિત થાય છે. પેકેટ ફિલ્ટર પાસે ગંતવ્ય પોર્ટ 443 સાથે પહોંચે છે. તે બિંદુએ 8443 સાથે મેળ ખાતો નિયમ કદી ચાલુ થતો નથી, જોકે ક્લાયન્ટે લખ્યું 8443 હતું.

પ્રકાશિત પોર્ટ હજી પણ જોડાણ ટ્રેકિંગમાં હાજર છે, તેથી જ્યારે ખરેખર જરૂર પડે ત્યારે મૂળ ગંતવ્ય ત્યાં મેળવી શકાય છે.

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

ચેઇન: INPUT નહીં, DOCKER-USER

Docker ની iptables માર્ગદર્શિકા વપરાશકર્તા ફોરવર્ડિંગ નીતિને DOCKER-USER ચેઇનમાં મૂકે છે, જે Docker ના પોતાના ફોરવર્ડિંગ નિયમો પહેલા મૂલ્યાંકિત થાય છે. યજમાન સેવામાંથી INPUT ચેઇનમાં નકલ કરેલો નિયમ યજમાનને સંબોધિત ટ્રાફિક ફિલ્ટર કરે છે, કન્ટેનરમાં ફોરવર્ડ થતો ટ્રાફિક નહીં. આ ભૂલ એવો નિયમ બનાવે છે જે સાચો દેખાય છે અને કન્ટેનરના માર્ગ પર કોઈ અસર કરતો નથી.

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

નવા જોડાણોથી ચકાસો

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

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