OpenVPN ഉം HTTPS ഉം പോർട്ട് 443-ൽ: കേൾവിക്കാരൻ ആരുടേത്?
TCP ഉം UDP 443 ഉം വെവ്വേറെ സോക്കറ്റുകളാണ്. ഒരു TCP കേൾവിക്കാരനെ പങ്കിടാൻ ഉടമ വേണം, OpenVPN-ന്റെ പോർട്ട് പങ്കിടൽ ഒരു ഇടുങ്ങിയ കരാർ മാത്രമാണ്, പ്രോക്സി തന്ത്രമല്ല.
രണ്ട് സേവനങ്ങൾക്കും ഒരിക്കലും മത്സരിക്കാതെ 443 പോർട്ടിൽ ഉത്തരം നൽകാം, കാരണം കേൾവിക്കാരൻ സംഖ്യ കൊണ്ട് മാത്രമല്ല, ഗതാഗതം, വിലാസം, പോർട്ട് എന്നിവ ഒരുമിച്ചാണ് നിർണ്ണയിക്കുന്നത്. ഒരേ യന്ത്രത്തിൽ ഒരു വെബ് സെർവറും OpenVPN-ഉം വെക്കുക, ആദ്യം ഉത്തരം നൽകാൻ അർഹതയുള്ള ഒരേയൊരു ചോദ്യം ഓരോ പ്രോസസും കർണലിൽ നിന്ന് ഏത് സോക്കറ്റ് ആവശ്യപ്പെടുന്നു എന്നതാണ്. കോൺഫിഗറേഷൻ തിരുത്തുന്നതിന് മുൻപ് ആ പട്ടിക എഴുതി വെക്കുക, എന്നാൽ «വിലാസം ഇതിനകം ഉപയോഗത്തിലാണ്» എന്ന പിശകുകളിൽ മിക്കതും സ്വയം വിശദീകരിക്കും. പട്ടികയ്ക്ക് ശേഷമുള്ളതെല്ലാം UDP കേൾവിക്കാരൻ, പങ്കിട്ട TCP സോക്കറ്റ് അല്ലെങ്കിൽ പ്രോട്ടോക്കോൾ അനുസരിച്ച് റൂട്ട് ചെയ്യുന്ന മുൻഭാഗം എന്നിവയിൽ ഒന്ന് തിരഞ്ഞെടുക്കലാണ്.
ഓരോ പ്രോസസും ആവശ്യപ്പെടുന്ന സോക്കറ്റിൽ നിന്ന് തുടങ്ങുക
bind ആ ത്രികത്തിന്റെ അടിസ്ഥാനത്തിൽ വിജയിക്കുകയോ പരാജയപ്പെടുകയോ ചെയ്യുന്നു, അതിനാൽ മൂന്ന് ഭാഗങ്ങളും ഒത്തുചേരുമ്പോൾ മാത്രമാണ് രണ്ട് ഡീമണുകൾ കൂട്ടിയിടിക്കുന്നത്. അതുകൊണ്ടാണ് TCP 443-ലെ വെബ്സൈറ്റ് UDP 443-ലെ OpenVPN കേൾവിക്കാരനൊപ്പം അനിശ്ചിതമായി സഹവർത്തിക്കുന്നത്, അതുകൊണ്ടാണ് അവയിലൊന്നിനെ അതേ ഹോസ്റ്റിലെ രണ്ടാമത്തെ പ്രാദേശിക വിലാസത്തിലേക്ക് മാറ്റുന്നതും തർക്കം അവസാനിപ്പിക്കുന്നത്. ജീവനുള്ള കേൾവിക്കാരെ വായിക്കുക, അവയെ സൃഷ്ടിക്കേണ്ടിയിരുന്ന ഫയലുകളല്ല, കാരണം പഴയ include അല്ലെങ്കിൽ മറന്ന unit ഫയൽ നിങ്ങൾ ഓർക്കുന്ന തിരുത്തലിനെക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കും.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root ആയി ss -lntup പ്രവർത്തിപ്പിച്ച് 443 പരാമർശിക്കുന്ന ഓരോ വരിയും, IPv6 എൻട്രികൾ ഉൾപ്പെടെ, വായിക്കുക. സാധാരണയായി വൈൽഡ്കാർഡ് v6 കേൾവിക്കാരൻ v4 ട്രാഫിക്കും സ്വീകരിക്കും, അങ്ങനെയാണ് മറന്ന കേൾവിക്കാരൻ നിങ്ങൾ ഉത്തരവാദിയെന്ന് കരുതിയ ഫയൽ മാറ്റിയതിന് ശേഷവും പോർട്ട് കൈവശം വെക്കുന്നത്. പ്രോസസിന്റെ പേര് നിങ്ങളെ അമ്പരപ്പിച്ചാൽ, എന്തെങ്കിലും തൊടുന്നതിന് മുൻപ് ss -lntup 'sport = :443' ഉപയോഗിച്ച് ഔട്ട്പുട്ട് ചുരുക്കുക.
നെറ്റ്വർക്ക് അനുവദിക്കുമ്പോൾ ടണൽ UDP-ലേക്ക് മാറ്റുക
UDP കേൾവിക്കാരൻ കൂട്ടിയിടി പൂർണ്ണമായി ഒഴിവാക്കുന്നു, സാധാരണയായി ഏറ്റവും ചെറിയ അറ്റകുറ്റപ്പണിയാണ്, കാരണം സോക്കറ്റ് പങ്കിടുന്നില്ല, പാതയിൽ അധിക ഉൽപ്പന്നവും കടക്കുന്നില്ല. പക്ഷേ അത് സൗജന്യമല്ല. ചില ക്ലയന്റ് നെറ്റ്വർക്കുകൾ reset അയക്കാതെ UDP 443 ഉപേക്ഷിക്കുന്നു, അതിനാൽ ടണൽ bind-ൽ പരാജയപ്പെടുന്നതിന് പകരം സ്ഥാപിക്കുന്നത് നിർത്തുന്നു, ഉപയോക്താവ് വായിക്കാൻ പിശകില്ലാതെ VPN നിലച്ചു എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. UDP കേൾവിക്കാരൻ വെബ് പാളിയുടെ പുനരാരംഭവും അതിജീവിക്കുന്നു, സൈറ്റ് പതിവായി വീണ്ടും വിന്യസിക്കുന്ന യന്ത്രത്തിൽ അത് പ്രധാനമാണ്. ഉപയോക്താക്കൾ ഇരിക്കുന്ന നെറ്റ്വർക്കിൽ നിന്ന് പരീക്ഷിക്കുക, കാരണം സെർവറിലെ shell സെർവർ സ്വയം എത്തുന്നു എന്ന് മാത്രമാണ് തെളിയിക്കുന്നത്.
സെർവർ കോൺഫിഗറേഷനിലും ക്ലയന്റ് പ്രൊഫൈലിലും ഗതാഗതം ഒരുമിച്ച് മാറ്റുക. ഇപ്പോഴും TCP ആവശ്യപ്പെടുന്ന പ്രൊഫൈൽ UDP മാത്രമുള്ള കേൾവിക്കാരനെതിരെ വീണ്ടും ബന്ധിപ്പിക്കൽ ചക്രങ്ങളിൽ കറങ്ങും, രണ്ട് ഫയലുകളും താരതമ്യം ചെയ്യുന്നത് വരെ അത് നെറ്റ്വർക്ക് തകരാറായി തോന്നും.
VPN പ്രോസസിന് TCP 443 കൈവശം വെക്കാൻ അനുവദിച്ച് ബാക്കി കൈമാറുക
TCP സെർവർ മോഡിൽ Community OpenVPN വരുന്ന കണക്ഷന്റെ ആദ്യ ബൈറ്റുകൾ വായിച്ച് സ്വന്തം പ്രോട്ടോക്കോൾ അല്ലാത്തതെല്ലാം HTTPS ബാക്കെൻഡിലേക്ക് കൈമാറുന്നു, port-share നിർദ്ദേശം അതിനാണ്. ബാക്കെൻഡ് TLS പ്രവർത്തനക്ഷമമാക്കിയ സാധാരണ വെബ് സെർവറാണ്, ആ നിർദ്ദേശത്തിൽ URL കൊണ്ടല്ല, ഹോസ്റ്റും പോർട്ടും കൊണ്ടാണ് അതിനെ പേരിടുന്നത്.
port-share 10.0.0.5 8080
സൈറ്റിന് രണ്ടാമത്തെ സ്വകാര്യ വിലാസമുള്ള യന്ത്രത്തിൽ ആ വരി VPN അല്ലാത്ത ട്രാഫിക്കിനെ 10.0.0.5:8080-ലേക്ക് അയക്കുന്നു, അതിനാൽ HTTPS വെർച്വൽ ഹോസ്റ്റ് അവിടെ ബൈൻഡ് ചെയ്തിരിക്കണം, ഫയർവാൾ പ്രാദേശിക ചാട്ടം അനുവദിക്കണം. വെബ് സെർവർ TLS സ്വയം അവസാനിപ്പിക്കണം, കാരണം വരുന്ന ബൈറ്റുകൾ ബ്രൗസറിന്റെ യഥാർത്ഥ ഹാൻഡ്ഷേക്കാണ്, ഇടയിൽ ഒന്നും അവ ഡീക്രിപ്റ്റ് ചെയ്തിട്ടില്ല. നിർദ്ദേശം സാധാരണ HTTP കേൾവിക്കാരനിലേക്ക് തിരിച്ചാൽ ബ്രൗസറിന് അസാധുവായ രീതി പിശക് ലഭിക്കും, അത് ബാക്കെൻഡ് തെറ്റായ സ്ഥലത്ത് എന്നതിനേക്കാൾ തകർന്ന സൈറ്റായി വായിക്കപ്പെടും. നിർദ്ദേശം TCP സെർവർ മോഡിൽ മാത്രമേ ഉള്ളൂ, UDP കേൾവിക്കാരന് പരിശോധിക്കാൻ സ്ട്രീമില്ല.
VPN പ്രോസസ് ഓരോ കണക്ഷനും സ്വീകരിക്കുന്നതിനാൽ, വെബ് ആപ്ലിക്കേഷൻ കൈമാറിയ അഭ്യർത്ഥന സന്ദർശകനിൽ നിന്നല്ല, ഹോസ്റ്റിന്റെ സ്വന്തം വിലാസങ്ങളിൽ ഒന്നിൽ നിന്ന് വരുന്നതായി കാണുന്നു. യഥാർത്ഥ ക്ലയന്റ് വിലാസം വേണ്ടതെല്ലാം ബാക്കെൻഡിലെ PROXY പ്രോട്ടോക്കോൾ പിന്തുണയെയോ അത് ചേർക്കുന്ന മുൻഭാഗത്തെയോ ആശ്രയിച്ചിരിക്കുന്നു. ബാക്കെൻഡിനെ മറ്റൊരു പ്രാദേശിക വിലാസത്തിലേക്ക് മാറ്റുന്നത് സന്ദർശകന്റെ വിലാസം തിരികെ കൊണ്ടുവരുന്നില്ല; സൈറ്റ് ഹോസ്റ്റിന്റെ ഏത് വിലാസങ്ങൾ രേഖപ്പെടുത്തുന്നു എന്നത് മാത്രം മാറ്റുന്നു. അനലിറ്റിക്സ് റിപ്പോർട്ട് ചോദ്യം ഉയർത്തുന്നതിന് മുൻപ് ഈ പരിമിതി വിന്യാസ കുറിപ്പുകളിൽ എഴുതുക.
റിവേഴ്സ് പ്രോക്സി തെറ്റായ ഉപകരണമാണ്; ലെയർ-നാല് റൂട്ടർ അല്ല
HTTP റിവേഴ്സ് പ്രോക്സി അഭ്യർത്ഥനകൾ വായിക്കാൻ TLS അവസാനിപ്പിക്കുന്നു, അതായത് OpenVPN സ്ട്രീം തൊടാതെ കടത്തിവിടാൻ അതിന് കഴിയില്ല. SNI അല്ലെങ്കിൽ ആദ്യ പാക്കറ്റ് പരിശോധന പ്രകാരം കൈമാറുന്ന ലെയർ-നാല് റൂട്ടർ, VPN ആശ്രയിക്കുന്ന സെഷൻ അവസാനിപ്പിക്കുന്നില്ലെങ്കിൽ രണ്ടിന്റെയും മുന്നിൽ നിൽക്കാം. രണ്ട് ഉപകരണങ്ങളും ഡയഗ്രാമിൽ ഒരുപോലെ തോന്നും, സോക്കറ്റിൽ തികച്ചും വ്യത്യസ്തമായി പെരുമാറും.
വാണിജ്യ Access Server അതിന്റെ സ്വന്തം പോർട്ട് പങ്കിടൽ ക്രമീകരണങ്ങളുമായി വരുന്നു, അവ കമ്മ്യൂണിറ്റി നിർദ്ദേശവുമായി ഒന്നിനൊന്ന് ഒത്തുപോകുന്നില്ല. മറ്റൊന്നിനായി എഴുതിയ ഗൈഡ് പൊരുത്തപ്പെടുത്തുന്നതിന് മുൻപ് ഉൽപ്പന്നവും പതിപ്പും തിരിച്ചറിയുക. നിശബ്ദമായി അവഗണിക്കപ്പെടുന്ന പകർത്തിയ ക്രമീകരണം ക്രമീകരണം ഇല്ലാത്തതിനേക്കാൾ മോശമാണ്, കാരണം അതിന് ശേഷവും കേൾവിക്കാരുടെ പട്ടിക വിശ്വസനീയമായി തോന്നും.
വെബ്സൈറ്റും ടണലും രണ്ട് വേറിട്ട പാതകളായി പരീക്ഷിക്കുക
സൈറ്റ് ലോഡ് ചെയ്ത് ടണൽ ബന്ധിപ്പിക്കുക, എന്നിട്ട് 443 ഇപ്പോൾ ഏത് പ്രോസസിന്റെ കൈവശമാണെന്ന് കാണാൻ കേൾവിക്കാരുടെ പട്ടിക വീണ്ടും വായിക്കുക. ലോഡ് ചെയ്യുന്ന പേജ് VPN-നെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, ബന്ധിപ്പിക്കുന്ന ടണൽ സൈറ്റിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, രണ്ടും ഒരേ സംഖ്യ ഉപയോഗിക്കുന്നുവെങ്കിലും. താഴെയുള്ള മൂന്ന് കമാൻഡുകൾ പങ്കിട്ട സോക്കറ്റ്, വെബ് പാത, VPN സേവനം എന്നിവ ആ ക്രമത്തിൽ പരിശോധിക്കുന്നു.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
അതേ നിമിഷത്തിലെ ബാക്കെൻഡ് ആക്സസ് ലോഗിലെ ക്ലയന്റ് വിലാസം VPN ലോഗിലെ വിലാസവുമായി താരതമ്യം ചെയ്യുക. സൈറ്റ് ഓരോ സന്ദർശകനെയും ഹോസ്റ്റ് തന്നെയായി രേഖപ്പെടുത്തുന്നുവെങ്കിൽ കൈമാറ്റം പ്രവർത്തിക്കുന്നു, വിലാസ കൈകാര്യം ചെയ്യൽ പ്രവർത്തിക്കുന്നില്ല. രണ്ട് ലോഗുകളും നിശബ്ദമാണെങ്കിൽ മുൻഭാഗം ഒരിക്കലും കണക്ഷൻ ഏൽപ്പിച്ചിട്ടില്ല. ഏതായാലും സോക്കറ്റ് ആരു സ്വീകരിക്കുന്നു എന്നത് കേൾവിക്കാരുടെ പട്ടിക തീരുമാനിക്കുന്നു, മറ്റൊരു ഫയൽ മാറ്റുന്നതിന് മുൻപ് സ്ഥിരീകരിക്കേണ്ട വസ്തുത അതാണ്.
ആ കേൾവിക്കാരുടെ ഭൂപടം കോൺഫിഗറേഷന്റെ അരികിൽ വെക്കുക, അങ്ങനെ 443 തൊടുന്ന അടുത്ത വ്യക്തിക്ക് ഏത് പ്രോസസ് സ്വീകരിക്കുന്നു, മറ്റേ പ്രോട്ടോക്കോൾ എങ്ങോട്ട് പോയി എന്ന് അറിയാം. തിരുത്തൽ എന്ത് ചെയ്യണമായിരുന്നു എന്നതിൽ വിശ്വസിക്കുന്നതിന് പകരം മാറ്റത്തിന് ശേഷം ഉടമസ്ഥത സ്ഥിരീകരിക്കുക.