Docker પોર્ટ પ્રકાશન વિરુદ્ધ VPN: જવાબ ક્યાં જાય છે

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

ગંતવ્ય NAT દ્વારા ટ્યુપલને અનુસરો

એક હોસ્ટ લો 192.0.2.10 પર, જે TCP 2222 ને 172.30.240.5:22 પરના કન્ટેનરમાં પ્રકાશિત કરે છે. 198.51.100.25 તરફથી આવતી વિનંતી કન્ટેનર સુધી પહોંચતાં પહેલાં અનુવાદિત થાય છે, અને કન્ટેનર પોતાના તરીકે જવાબ આપે છે.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

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

કેમ ફક્ત હોસ્ટ માટેનો નિયમ તેને ચૂકી જાય છે

એ નિયમ જે ફક્ત 192.0.2.10 તરફથી આવતા પેકેટ માટે WAN ટેબલ પસંદ કરે છે, તે હોસ્ટના પોતાના ડિમનને આવરે છે અને આ ફોરવર્ડ થયેલ જવાબને સંપૂર્ણ ચૂકી જાય છે. જવાબ પરનું સ્રોત સરનામું 172.30.240.5 છે, હોસ્ટ નહીં.

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

DNAT પછીની મેચિંગ એ બીજું હૂક છે

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

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

ડિઝાઇન A: નિર્ણયને કનેક્શન સ્થિતિ તરીકે લઈ જાઓ

કનેક્શન માર્ક ઇનગ્રેસ નિર્ણયને અનુવાદ દ્વારા લઈ જઈ શકે છે, પરંતુ મહત્વના રૂટ લુકઅપ પહેલાં તેને પેકેટ પર પુનઃસ્થાપિત કરવો પડે છે. તબક્કા આ છે:

1. એવું માર્ક ફીલ્ડ અને નિયમ પ્રાથમિકતા અનામત રાખો જે Docker, VPN કે અન્ય નીતિ-માલિક સાથે અથડાય નહીં.
2. ફક્ત ઇચ્છિત નવું WAN કનેક્શન pre-DNAT બિંદુ પર ઓળખો જ્યાં કનેક્શન ટ્રેકિંગ ઉપલબ્ધ હોય.
3. મૂળ વિનંતીને જાતે WAN ટેબલમાં ફોર્સ કર્યા વિના નિર્ણયને કનેક્શન માર્ક પર નોંધો.
4. જવાબની દિશામાં, રૂટિંગ પહેલાં પેકેટ પર ફક્ત તમારા પોતાના માર્ક બિટ્સ પુનઃસ્થાપિત કરો.
5. પૂરતું વહેલું સંપૂર્ણ WAN ટેબલ પસંદ કરો જેથી VPN નિયમ પહેલો જીતી ન શકે.

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

ડિઝાઇન B: હોસ્ટ પર સમાપ્ત કરો

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

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

ફેરફાર ચકાસો, ઇરાદો નહીં

જાહેર બાજુથી નવું અધિકૃત કનેક્શન ખોલો અને ખાતરી કરો કે જવાબ ઇચ્છિત ઇન્ટરફેસમાંથી નીકળે છે. પછી તપાસો કે કન્ટેનરે શરૂ કરેલી અસંબંધિત વિનંતી હજી પણ VPN ને અનુસરે છે.

એક નિયમ ચકાસવા માટે મશીનનું કનેક્શન ટેબલ ફ્લશ કરશો નહીં: હાલની એન્ટ્રીઓ તેમનું અગાઉનું મેપિંગ રાખે છે, અને ફ્લશ હોસ્ટ પરનું બાકીનું બધું તોડી નાખે છે. પોર્ટ પ્રકાશિત કરવો પહોંચવાની ક્ષમતા નક્કી કરે છે. તે જવાબનો માર્ગ નક્કી કરતું નથી. પસંદ કરેલી ડિઝાઇન તેના ટેબલ નામો સાથે લખી રાખો, જેથી આગલી વ્યક્તિને ઘટનાના સમયે તે ફરીથી શોધવી ન પડે.