Meshnet, Docker અને વચ્ચેની પરવાનગી

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

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

પ્રકાશન પછી ગંતવ્યને અનુસરો

Linux Docker હોસ્ટ લો જે કન્ટેનરનું પોર્ટ 80 હોસ્ટના પોર્ટ 8080 પર પ્રકાશિત કરે છે. એક પીઅર 8080 પર હોસ્ટના મેશ સરનામે જોડાય છે, હોસ્ટ જોડાણ સ્વીકારે છે, અને ગંતવ્યનો અનુવાદ તેને કન્ટેનરના બ્રિજ સરનામા તરફ ફરીથી લખે છે, સામાન્ય રીતે 172.17.0.2 જેવું કંઈક, પોર્ટ 80 પર.

જ્યારે કોઈ નિયમ એ પ્રવાહની તપાસ કરે છે ત્યારે રસનું ગંતવ્ય કન્ટેનર છે, હોસ્ટ નહીં. જે નીતિ ફક્ત «આ મશીન પરની સેવા» વિશે વિચારે છે તે ખોટી વસ્તુ વિશે વિચારે છે. વિનંતી હોસ્ટ પર ઉતરી, પણ તે બીજે ક્યાંક પહોંચાડવામાં આવે છે.

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

પરવાનગી કેટલી સ્થાનિક ઍક્સેસ આપે છે તે નક્કી કરો

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

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

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

પરવાનગી ચકાસો, ફક્ત URL નહીં

મંજૂર પીઅરથી ચોક્કસ સેવા ખોલો અને તે કામ કરે છે તેની ખાતરી કરો. પછી એવા ગંતવ્યનો પ્રયાસ કરો જે નકારેલું જ રહેવું જોઈએ અને ખાતરી કરો કે તે કામ કરતું નથી. ફક્ત સુખદ માર્ગ ચકાસવો તમને કહે છે કે પરવાનગી આપવામાં આવી; તે કહેતું નથી કે સીમા તમે ધારો છો ત્યાં જ છે.

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

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

તારણને સિસ્ટમની પોતાની શબ્દાવલીમાં લખો

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

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