VPN ക്ലയന്റിനായി NGINX ഏത് ഉറവിട വിലാസം ലോഗ് ചെയ്യും?
ഒരേ ഹോസ്റ്റിൽ OpenVPN-നൊപ്പം NGINX എന്തു കാണുന്നു എന്ന് തീരുമാനിക്കുക: ആന്തരിക ടണൽ വിലാസം, പൊതു പുറത്തേക്കുള്ള വിലാസം അല്ലെങ്കിൽ കൈമാറിയ പിയർ, സ്വീകരിച്ച പാത അനുസരിച്ച്.
ഒരേ ഹോസ്റ്റിലെ NGINX, OpenVPN ക്രമീകരണത്തിൽ മൂന്ന് ക്ലയന്റ് വിലാസങ്ങൾ കാണാം, അഭ്യർത്ഥന സ്വീകരിക്കാവുന്ന ഓരോ പാതയ്ക്കും ഓരോന്ന്. ടണൽ വിലാസത്തിൽ എത്തുന്ന ബ്രൗസർ, പൊതു വിലാസത്തിൽ എത്തുന്ന ബ്രൗസർ, ഗേറ്റ്‌വേയുടെ ഇന്റർനെറ്റ് പാതയിലൂടെ പുറത്തുപോകുന്ന പ്രോഗ്രാം എന്നിവ കേൾക്കുന്ന സോക്കറ്റിൽ വ്യത്യസ്തമായി കാണപ്പെടുന്നു. ലോഗ് വരി വ്യാഖ്യാനിക്കുന്നതിന് മുമ്പ് ഏത് പാതയാണ് നിങ്ങൾ നോക്കുന്നതെന്ന് തീരുമാനിക്കുക. തീരുമാനം ക്ലയന്റ് ഉപയോഗിച്ച ലക്ഷ്യത്തെയും, പുറം VPN അന്ത്യബിന്ദുവിനായി അത് സൂക്ഷിക്കുന്ന ഒഴിവിനെയും, വഴിയിൽ എന്തെങ്കിലും പാക്കറ്റ് വിവർത്തനം ചെയ്യുന്നുണ്ടോ എന്നതിനെയും ആശ്രയിച്ചിരിക്കുന്നു.
ഉപയോക്താവ് ആരെന്നതല്ല, ലക്ഷ്യം നോക്കി തീരുമാനിക്കുക
അഭ്യർത്ഥന അയച്ച വിലാസത്തിൽ തുടങ്ങുക, കാരണം ആ വിലാസമാണ് പാത തിരഞ്ഞെടുക്കുന്നത്. ഹോസ്റ്റിന്റെ ടണൽ വിലാസത്തിലേക്കുള്ള അഭ്യർത്ഥന ക്ലയന്റിന്റെ ആന്തരിക വിലാസം ഉറവിടമായി വഹിച്ച് ടണൽ ഇന്റർഫേസിൽ എത്തുന്നു. ഹോസ്റ്റിന്റെ പൊതു വിലാസത്തിലേക്കുള്ള അഭ്യർത്ഥന സാധാരണയായി ഇന്റർനെറ്റിലേക്ക് അഭിമുഖീകരിക്കുന്ന ഇന്റർഫേസിൽ ക്ലയന്റിന്റെ പൊതു വിലാസത്തോടെ എത്തുന്നു, അതേ ലാപ്‌ടോപ്പിൽ ആ നിമിഷം ടണൽ സ്ഥാപിച്ചിരുന്നാലും. അതിനാൽ VPN പൂളിലെ അംഗത്വം പാക്കറ്റ് പാതയുടെ സ്വഭാവമാണ്, ഉപയോക്താവിനെ പിന്തുടരുന്ന സ്വഭാവമല്ല.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
ടണലുമായി യാതൊരു ബന്ധവുമില്ലാത്ത വിലാസത്തോടെ ഒരു VPN ഉപയോക്താവ് ലോഗിൽ പ്രത്യക്ഷപ്പെടുമ്പോൾ ആദ്യം പരിശോധിക്കേണ്ടത് ഈ മൂന്നാം വരിയാണ്. ഒരേ പ്രൊഫൈലിലെ രണ്ട് ഉപയോക്താക്കൾക്ക് വ്യത്യസ്ത രേഖകൾ ഉണ്ടാക്കാൻ കഴിയുന്നത് എന്തുകൊണ്ടെന്നും ഇത് വിശദീകരിക്കുന്നു: അവരുടെ സ്വന്തം ആക്സസ് നെറ്റ്‌വർക്കുകൾ വ്യത്യസ്തമാണ്, ടണലിനുള്ളിൽ ഒന്നും അതിന് മേലെഴുതുന്നുമില്ല.
പുറം അന്ത്യബിന്ദു രണ്ടാമതൊരു പൊതു പാത സൃഷ്ടിക്കുന്നത് എന്തുകൊണ്ട്
ടണൽ സ്ഥാപിക്കാൻ ക്ലയന്റ് ഗേറ്റ്‌വേയുടെ പൊതു വിലാസത്തിൽ എത്തണം, അതിനാൽ ആ വിലാസത്തിലേക്കുള്ള റൂട്ട് ടണലിന് പുറത്ത് നിലനിൽക്കണം. ക്ലയന്റ് എല്ലാ ട്രാഫിക്കും ഉള്ളിലേക്ക് തിരിക്കുമ്പോൾ, സ്വയം ആശ്രയിക്കുന്ന ടണൽ ഒഴിവാക്കാൻ വിവേകമുള്ള നടപ്പാക്കൽ സെർവറിന്റെ പൊതു വിലാസത്തിലേക്ക് വ്യക്തമായ ഹോസ്റ്റ് റൂട്ട് സൂക്ഷിക്കുന്നു. ആ ഒഴിവ് സേവനങ്ങളുടെ കാര്യത്തിൽ തിരഞ്ഞെടുപ്പ് നടത്തുന്നില്ല, അതിനാൽ അതേ പൊതു വിലാസത്തിലേക്കുള്ള ഏത് അഭ്യർത്ഥനയും അത് പിന്തുടരുന്നു, ഗേറ്റ്‌വേയിൽ ഹോസ്റ്റ് ചെയ്യുന്ന സൈറ്റിലേക്കുള്ള ബ്രൗസർ അഭ്യർത്ഥനയും ഉൾപ്പെടെ.
ഈ മേഖലയിലെ മിക്ക ആശയക്കുഴപ്പമുള്ള റിപ്പോർട്ടുകൾക്കും പിന്നിലുള്ള സംവിധാനം ഇതാണ്, അത് സെർവറിനെയല്ല, ക്ലയന്റ് നടപ്പാക്കലിനെ ആശ്രയിച്ചിരിക്കുന്നു. അതിനാൽ ഒരേ പ്രൊഫൈലുള്ള രണ്ട് ക്ലയന്റുകൾക്ക് വ്യത്യസ്തമായി പെരുമാറാം. ലോഗ് »നന്നാക്കാൻ« ഒഴിവ് നീക്കിയാൽ ടണലും കൂടി വീഴും, അതിനാൽ അത് നിലനിർത്തി അതിനു ചുറ്റും രൂപകൽപ്പന ചെയ്യുക.
സോക്കറ്റ്, പട്ടിക, ലോഗ് ഫോർമാറ്റ് എന്നിവ ഒരുമിച്ച് വായിക്കുക
നിങ്ങൾ ഏത് പാത നോക്കുന്നു എന്ന് മൂന്ന് നിരീക്ഷണങ്ങൾ തീരുമാനിക്കുന്നു: സോക്കറ്റ് എവിടെ കേൾക്കുന്നു, ഏത് ഇന്റർഫേസ് ലക്ഷ്യത്തിന് ഉത്തരം നൽകുന്നു, ലോഗ് ഫോർമാറ്റ് യഥാർത്ഥത്തിൽ എന്ത് രേഖപ്പെടുത്തുന്നു. ശ്രോതാവ് ടണൽ വിലാസത്തിൽ മാത്രം ബന്ധിതമാണെങ്കിൽ, പൊതു അഭ്യർത്ഥന അവിടെ എത്താൻ കഴിയില്ല, ഇത് ഉടൻ രണ്ട് വരികൾ ഒഴിവാക്കുന്നു. ക്ലയന്റിനായുള്ള തിരച്ചിൽ ടണൽ ഉപകരണം തിരികെ നൽകുന്നുവെങ്കിൽ, അഭ്യർത്ഥന ആന്തരിക ഉറവിടത്തോടെ എത്തിയിട്ടുണ്ട്, ലോഗ് അത് കാണിക്കേണ്ടതാണ്.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44പിന്നെ വരിയല്ല, ഫോർമാറ്റ് വായിക്കുക. കൈമാറിയ ഹെഡറിൽ നിന്ന് നിറയുന്ന ഫീൽഡ് സോക്കറ്റ് പിയറല്ല, ഒരു അവകാശവാദം രേഖപ്പെടുത്തുന്നു, അവകാശവാദം തൽക്ഷണ പിയർ വിശ്വസനീയമായ പ്രോക്സി ആയാൽ മാത്രമേ പ്രസക്തമാകൂ. രണ്ട് മൂല്യങ്ങളും ലോഗിൽ എഴുതുന്നത് പിന്നീടുള്ള തർക്കങ്ങൾ തീർക്കുന്നു, കാരണം തൽക്ഷണ പിയറും മാറ്റിസ്ഥാപിച്ച വിലാസവും വ്യത്യസ്ത വസ്തുതകളാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് നെറ്റ്‌വർക്കിൽ നിന്ന് വന്നത്.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confആവശ്യമുള്ള പ്രവേശന കേന്ദ്രം തിരഞ്ഞെടുത്ത് DNS യോജിപ്പിക്കുക
സൈറ്റ് ടണൽ വഴി മാത്രമായിരിക്കണമെങ്കിൽ, VPN ക്ലയന്റുകൾക്ക് ടണൽ വിലാസത്തിലേക്ക് പരിഹരിക്കുന്ന ഒരു പേര് നൽകി കേൾക്കുന്ന സോക്കറ്റിൽ നയം നടപ്പാക്കുക. ആന്തരിക നാമത്തിന് 10.24.0.1 തിരികെ നൽകുന്ന വിഭജിത DNS ഉത്തരം നാമപരിഹാരത്തിന്റെ വിശദാംശത്തിന്റെ വേഷത്തിലുള്ള റൂട്ടിംഗ് തീരുമാനമാണ്. സൈറ്റ് പൊതുവായും വേണമെങ്കിൽ, രണ്ട് പേരുകളോ രണ്ട് പോർട്ടുകളോ നിലനിർത്തി, ഏതാണ് അഭ്യർത്ഥന നിർവഹിച്ചതെന്ന് ലോഗ് പറയട്ടെ.
അനുവദനീയ നിയമങ്ങൾ അതേ യുക്തി പിന്തുടരുന്നു. ടണൽ പൂൾ അനുവദിക്കുന്നത് പൊതു അഭ്യർത്ഥനയ്ക്ക് അധികാരം നൽകുന്നില്ല, ഇന്റർനെറ്റിലൂടെ വന്ന കണക്ഷനിൽ ആന്തരിക വിലാസം നിറയ്ക്കുകയുമില്ല. രണ്ട് പ്രവേശന കേന്ദ്രങ്ങളും ഒരു പേരിന് കീഴിൽ കലർത്തുന്നത് രേഖപ്പെടുത്തിയ ഉറവിടത്തെ രൂപകൽപ്പനാ തിരഞ്ഞെടുപ്പിന് പകരം ക്ലയന്റ് റൂട്ടിംഗിന്റെ പാർശ്വഫലമാക്കുന്നു.
പാത പരിശോധിക്കുക, പിന്നെ നയം
ഗേറ്റ്‌വേയിലെ ക്യാപ്‌ചറും നിങ്ങൾ നിയന്ത്രിക്കുന്ന അഭ്യർത്ഥനയും ഉപയോഗിച്ച് പാത സ്ഥിരീകരിക്കുക. ടണൽ ഉപകരണത്തിലെ ക്യാപ്‌ചറും പൊതു ഇന്റർഫേസിലെ ഒന്നും ഏതാണ് ബൈറ്റുകൾ വഹിച്ചതെന്ന് കാണിക്കുന്നു, പാക്കറ്റുകളുടെ ക്രമം അവയ്ക്കിടയിൽ വിവർത്തനം നടന്നോ എന്ന് പറയുന്നു.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5പിന്നെ രണ്ട് ദിശകളിലും പ്രവേശനം പരിശോധിക്കുക: ഉദ്ദേശിച്ച പേരുള്ള പ്രവേശന കേന്ദ്രം ഉദ്ദേശിച്ച ക്ലയന്റിന് പ്രവർത്തിക്കുന്നു, അനുവദിക്കാത്ത പൊതു പാത മന്ദഗതിയാകുന്നതിന് പകരം നിരസിക്കപ്പെടുന്നു. ഒരു സാധാരണ IP-പ്രതിധ്വനി സൈറ്റ് ഗേറ്റ്‌വേയുടെ ഇന്റർനെറ്റ് പുറത്തേക്കുള്ള വഴിയെക്കുറിച്ച് എന്തോ തെളിയിക്കുന്നു, അതേ ഹോസ്റ്റിലെ ഈ സൈറ്റിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. പേജും WebSocket-ഉം യോജിക്കാതിരിക്കുമ്പോൾ, സെർവർ കോൺഫിഗറേഷൻ തൊടുന്നതിന് മുമ്പ് അവയുടെ URL, വിലാസ കുടുംബങ്ങൾ, DNS ഉത്തരങ്ങൾ എന്നിവ താരതമ്യം ചെയ്യുക.