તમારું Docker VPN પોર્ટ મેપિંગ ક્યારેય OpenVPN સુધી કેમ ન પહોંચે
હોસ્ટ પોર્ટ, કન્ટેનર પોર્ટ અને ટ્રાન્સપોર્ટ—ત્રણ અલગ નિર્ણયો. પ્રમાણપત્રોને અડવા પહેલાં એક UDP પ્રયાસને દરેક સીમામાંથી અનુસરો.
તમારું કન્ટેનર UDP 1195 પર સાંભળી શકે છે જ્યારે હોસ્ટ 1194 પ્રકાશિત કરે છે, અને મેપિંગ એમ કહે ત્યાં સુધી તે સાચું છે. સંખ્યાઓ ભાષાંતર કોષ્ટક બનાવે છે: ક્લાયન્ટ હોસ્ટ પોર્ટ પર ડાયલ કરે છે, Docker ગંતવ્યને કન્ટેનર પોર્ટ પર ફરીથી લખે છે, અને OpenVPN પોતાના રૂપરેખાંકનમાં નામ આપેલા પોર્ટ પર જવાબ આપે છે. આમાંની કોઈપણ કડીમાં અસંગતિ ફાયરવોલ જેવી દેખાતી શાંત નિષ્ફળતા ઉત્પન્ન કરે છે. પ્રમાણપત્રો અને સાઇફર આની નીચેની બાજુએ છે અને તેને સુધારી શકતા નથી.
પ્રમાણીકરણમાં કંઈપણ બદલતા પહેલાં એક પેકેટને ક્લાયન્ટથી પ્રક્રિયા સુધી અનુસરો.
ત્રણ સંખ્યાઓ, એક જોડાણ
ત્રણ સંખ્યાઓ એ ક્લાયન્ટ વાપરે છે તે દૂરનું ગંતવ્ય, હોસ્ટ પર પ્રકાશિત મેપિંગ અને કન્ટેનરની અંદરનો શ્રોતા છે. તે સમાન હોવી જરૂરી નથી, પણ શૃંખલા બનાવવી જોઈએ. સમાન સંખ્યાઓ એ ખાસ કિસ્સો છે જે સામાન્ય રીતે સૌથી સામાન્ય હોય છે, તેથી અસંગતિ એક વાર લખવી સહેલી અને પછી જોવી અઘરી હોય છે.
ડિબગ કરતા પહેલાં શૃંખલા એક લીટીમાં લખો: ક્લાયન્ટ સરનામું અને પોર્ટ, હોસ્ટ મેપિંગ, કન્ટેનર શ્રોતા, ટ્રાન્સપોર્ટ. શૃંખલામાંની ખામી એવી સંખ્યા તરીકે દેખાય છે જે અલગ મૂલ્યો સાથે બે વાર આવે છે.
| Location | Example |
|---|---|
| Remote client destination | Host address, UDP 1194 |
| Published mapping | Host UDP 1194 to container UDP 1195 |
| Container listener | OpenVPN on UDP 1195 |
ટૂંકી રચના ખરેખર શું કહે છે
ટૂંકા સ્વરૂપમાં ડાબી બાજુ હોસ્ટ પોર્ટ અને જમણી બાજુ કન્ટેનર પોર્ટ છે, અને સ્લેશ પ્રત્યય ટ્રાન્સપોર્ટ પસંદ કરે છે. પ્રત્યય છોડી દો તો Docker મેપિંગને TCP તરીકે ગણે છે, તેથી પ્રોટોકોલ વગરના મેપિંગ પાછળનો UDP શ્રોતા એવો શ્રોતા છે જ્યાં કોઈ પહોંચી શકતું નથી. આ ડિફોલ્ટ દસ્તાવેજીકૃત છે અને હજી પણ જેમણે સંખ્યાઓ મેળવીને કામ પૂરું ગણ્યું તેમને આશ્ચર્યમાં મૂકે છે.
લાંબું સ્વરૂપ બાઈન્ડ સરનામું અને પ્રોટોકોલ સ્પષ્ટપણે નિશ્ચિત કરે છે, જે નેટવર્ક તરફના કોઈપણ માટે વધારાની લીટીઓ વસૂલ કરે છે. જે ફાઇલે મેપિંગ બનાવ્યું તેના પર ભરોસો કરવાને બદલે પ્રકાશિત મેપિંગ ફરી વાંચો.
ports:
- 1194:1195/udpપેકેટ ક્યાં અટકી શકે છે
વિનંતી Docker પહેલાં, Docker માં અથવા શ્રોતા પર ફેંકી શકાય છે. Docker ની આગળ ક્લાઉડ ફાયરવોલ અથવા પોતાનું ફોરવર્ડિંગ કરતો રાઉટર હોઈ શકે છે, અને તે ઉપકરણને હોસ્ટ તરફનો પોર્ટ અને યોગ્ય ટ્રાન્સપોર્ટ જોઈએ. Docker ની અંદર ખોટા કન્ટેનર પોર્ટનું મેપિંગ બંધ સોકેટ તરફ મોકલે છે.
પછી શ્રોતા: OpenVPN નું રૂપરેખાંકન પોર્ટ અને પ્રોટોકોલનું નામ આપે છે, અને કન્ટેનરની અંદર બીજા પોર્ટ પર આવતો ક્લાયન્ટ કંઈ સુધી પહોંચતો નથી. UDP સેવાનું TCP થી પરીક્ષણ આ કોઈપણ તબક્કે કંઈ સાબિત કરતું નથી, તેથી ક્લાયન્ટ જે ટ્રાન્સપોર્ટ વાપરશે તે જ વાપરો.
બાઈન્ડ સરનામાં પહોંચ નક્કી કરે છે
લૂપબેક સાથે બંધાયેલું પ્રકાશિત મેપિંગ ફક્ત હોસ્ટથી જ પહોંચી શકાય છે, જ્યારે બધા ઇન્ટરફેસ સાથે બંધાયેલું ફાયરવોલ પરવાનગી આપે ત્યાં સુધી પહોંચી શકાય છે. સરનામું છોડી દેતી Compose ફાઇલમાં આ બંને સરખા દેખાય છે, અને Docker નો ડિફોલ્ટ પહોળો છે.
તૈનાતી કયું પ્રદર્શન ઇચ્છે છે તે નક્કી કરો, પછી તેને સ્પષ્ટ લખો. લૂપબેક દ્વારા જોડાતું આંતરિક પરીક્ષણ અને જોડાઈ ન શકતું દૂરનું ક્લાયન્ટ—બંને એક જ કન્ટેનરનું સચોટ વર્ણન હોઈ શકે.
ચાલુ સ્થિતિ વાંચો
ચાલુ કન્ટેનરનું અસરકારક મેપિંગ અને તેના નેટવર્ક નામસ્થાનમાંનો શ્રોતા તપાસો. કન્ટેનર શરૂ થયા પછી Compose ફાઇલ સંપાદિત થઈ હોઈ શકે, ઇમેજ મેટાડેટા પોર્ટ પ્રકાશિત કર્યા વગર જાહેર કરી શકે, અને બીજું કન્ટેનર પહેલેથી હોસ્ટ પોર્ટ ધરાવતું હોઈ શકે. ઇમેજમાં પોર્ટ જાહેર કરવો એ પ્રકાશિત કરવો નથી, અને બંન્નેમાંથી કોઈ સાંભળવા સમાન નથી.
ત્રણ અલગ સ્થિતિઓ, ત્રણ અલગ આદેશો, અને ફક્ત છેલ્લો OpenVPN ને લગતો છે.
મેપિંગ સાચું થયા પછી
પેકેટ OpenVPN સુધી પહોંચ્યા પછી તેનો લોગ TLS અને પ્રમાણીકરણ વિશે વાંચવાની જગ્યા છે. ક્યારેય ન આવેલા પેકેટને ઠીક કરવા પ્રમાણપત્રો ફરી બનાવવા એ બીજું ચલ ઉમેરતું વ્યર્થ કામ છે. મેપિંગની નોંધ ક્લાયન્ટ પ્રોફાઇલની બાજુમાં રાખો જેથી આગલી વ્યક્તિ ત્રણેય સંખ્યાઓ ફરી શોધવાને બદલે એક લીટી વાંચે. હોસ્ટ બાજુએ એક પેકેટ કેપ્ચર નક્કી કરે છે કે ત્રણ કડીમાંથી કઈ ખોટી છે, અને તેનો ખર્ચ પ્રમાણપત્ર ફરી બનાવવા કરતાં ઓછો છે.
અહીં વર્ણવેલો કિસ્સો બ્રિજ પ્રકાશન છે. હોસ્ટ નેટવર્કિંગ અને રૂટેડ કન્ટેનર સરનામાં ભાષાંતર છોડી દે છે, તેથી તે રચનાઓમાં એ જ સંખ્યાઓ બીજું કંઈક અર્થ ધરાવે છે.