നിങ്ങളുടെ 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 ഉപയോഗിച്ച് പരിശോധിക്കുന്നത് ഈ ഘട്ടങ്ങളിൽ ഒന്നിലും ഒന്നും തെളിയിക്കുന്നില്ല, അതിനാൽ ക്ലൈന്റ് ഉപയോഗിക്കാൻ പോകുന്ന ട്രാൻസ്പോർട്ട് തന്നെ ഉപയോഗിക്കുക.
ബൈൻഡ് വിലാസങ്ങൾ എത്തിച്ചേരാനുള്ള കഴിവ് തീരുമാനിക്കുന്നു
loopback-ലേക്ക് ബന്ധിച്ച പ്രസിദ്ധീകരിച്ച മാപ്പിംഗ് ഹോസ്റ്റിൽ നിന്ന് മാത്രം എത്താം, എല്ലാ ഇന്റർഫേസുകളിലേക്കും ബന്ധിച്ചത് ഫയർവാൾ അനുവദിക്കുന്നിടത്തെല്ലാം എത്താം. വിലാസം ഒഴിവാക്കുന്ന Compose ഫയലിൽ രണ്ടും ഒരുപോലെ കാണാം, Docker-ന്റെ സ്ഥിരസ്ഥിതി വിശാലമായതാണ്.
വിന്യാസം ഏത് വെളിപ്പെടുത്തലാണ് ഉദ്ദേശിക്കുന്നതെന്ന് തീരുമാനിച്ച് അത് വ്യക്തമായി എഴുതുക. loopback വഴി ബന്ധിപ്പിക്കുന്ന ആന്തരിക പരിശോധനയും ബന്ധിപ്പിക്കാനാകാത്ത ദൂരസ്ഥ ക്ലൈന്റും ഒരേ കണ്ടെയ്നറിന്റെ കൃത്യമായ വിവരണങ്ങളാകാം.
പ്രവർത്തിക്കുന്ന അവസ്ഥ വായിക്കുക
പ്രവർത്തിക്കുന്ന കണ്ടെയ്നറിന്റെ യഥാർത്ഥ മാപ്പിംഗും അതിന്റെ നെറ്റ്വർക്ക് നാമസ്ഥലത്തിലെ ശ്രോതാവും പരിശോധിക്കുക. കണ്ടെയ്നർ ആരംഭിച്ചതിന് ശേഷം Compose ഫയൽ തിരുത്തിയിരിക്കാം, ഇമേജ് മെറ്റാഡാറ്റ പോർട്ട് പ്രസിദ്ധീകരിക്കാതെ പ്രഖ്യാപിച്ചിരിക്കാം, രണ്ടാമത്തെ കണ്ടെയ്നർ ഇതിനകം ഹോസ്റ്റ് പോർട്ട് കൈവശം വച്ചിരിക്കാം. ഇമേജിൽ പോർട്ട് പ്രഖ്യാപിക്കുന്നത് അത് പ്രസിദ്ധീകരിക്കലല്ല, രണ്ടും ശ്രവിക്കുന്നതിന് തുല്യവുമല്ല.
മൂന്ന് വ്യത്യസ്ത അവസ്ഥകൾ, മൂന്ന് വ്യത്യസ്ത കമാൻഡുകൾ, അവസാനത്തേത് മാത്രം OpenVPN-മായി ബന്ധപ്പെട്ടതാണ്.
മാപ്പിംഗ് ശരിയായതിന് ശേഷം
പാക്കറ്റ് OpenVPN-ൽ എത്തിയാൽ, അതിന്റെ ലോഗ് TLS-നെയും ഓതന്റിക്കേഷനെയും കുറിച്ച് വായിക്കാനുള്ള സ്ഥലമാണ്. ഒരിക്കലും എത്താത്ത പാക്കറ്റ് ശരിയാക്കാൻ സർട്ടിഫിക്കറ്റുകൾ വീണ്ടും ഉണ്ടാക്കുന്നത് രണ്ടാമതൊരു ചരം കൂട്ടിച്ചേർക്കുന്ന പാഴ്വേലയാണ്. മാപ്പിംഗ് കുറിപ്പ് ക്ലൈന്റ് പ്രൊഫൈലിന് അടുത്ത് സൂക്ഷിക്കുക, അടുത്ത വ്യക്തി മൂന്ന് അക്കങ്ങളും വീണ്ടും കണ്ടെത്തുന്നതിന് പകരം ഒരു വരി വായിക്കും. ഹോസ്റ്റ് ഭാഗത്ത് ഒരിക്കൽ പാക്കറ്റ് പിടിച്ചെടുക്കുന്നത് മൂന്ന് കണ്ണികളിൽ ഏതാണ് തെറ്റെന്ന് തീരുമാനിക്കുന്നു, അതിന്റെ ചെലവ് സർട്ടിഫിക്കറ്റ് പുതുക്കുന്നതിനേക്കാൾ കുറവാണ്.
ഇവിടെ വിവരിച്ചത് പാലം വഴിയുള്ള പ്രസിദ്ധീകരണമാണ്. ഹോസ്റ്റ് നെറ്റ്വർക്കിംഗും റൂട്ട് ചെയ്ത കണ്ടെയ്നർ വിലാസങ്ങളും വിവർത്തനം ഒഴിവാക്കുന്നു, അതിനാൽ ആ രൂപകൽപ്പനകളിൽ അതേ അക്കങ്ങൾ മറ്റൊരു അർത്ഥം നൽകുന്നു.