ഗേറ്റ്വേയിൽ OpenVPN ക്ലയന്റിന്റെ ട്രാഫിക് എവിടെ നിരീക്ഷിക്കണം

ബന്ധിപ്പിച്ച ക്ലയന്റ് ഏത് ലക്ഷ്യങ്ങളിലേക്ക് എത്തുന്നു എന്ന് അറിയാൻ ആഗ്രഹിക്കുന്നു, അതിനാൽ VPN സെർവറിൽ ഒരു ഷെൽ തുറന്ന് ss എന്ന് ടൈപ്പ് ചെയ്യുന്നു. ഉപയോഗപ്രദമായ ഒന്നും പ്രത്യക്ഷപ്പെടുന്നില്ല, ടണൽ തകർന്നു എന്ന നിഗമനം അൽപ്പം അധികം എളുപ്പത്തിൽ വരുന്നു. റൂട്ട് ചെയ്ത OpenVPN ഗേറ്റ്വേ ക്ലയന്റിന്റെ പാക്കറ്റുകൾ കൈമാറുന്നു; അത് അവയുടെ TCP കണക്ഷനുകൾ അവസാനിപ്പിക്കുന്നില്ല, അവയ്ക്കായി സോക്കറ്റുകൾ സൂക്ഷിക്കുന്നുമില്ല. തെളിവ് മറ്റെവിടെയോ ജീവിക്കുന്നു, എവിടെ എന്നത് ടണൽ വിട്ടതിന് ശേഷം ട്രാഫിക് എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

നിങ്ങൾ ഏത് ക്രമീകരണമാണ് നോക്കുന്നതെന്ന് തീരുമാനിക്കുക

രണ്ട് സാധാരണ രൂപങ്ങൾ തികച്ചും വ്യത്യസ്തമായ തെളിവുകൾ നൽകുന്നു. റൂട്ടിംഗ് ഗേറ്റ്വേ ഡീകാപ്സുലേറ്റ് ചെയ്യുന്നു, കൈമാറുന്നു, ചിലപ്പോൾ സ്രോതസ്സ് NAT ചെയ്യുന്നു, അതിനാൽ ക്ലയന്റിന്റെ കണക്ഷൻ പ്രാദേശിക സോക്കറ്റ് ഇല്ലാതെ അറ്റം മുതൽ അറ്റം വരെ തുടരുന്നു.

പ്രോക്സി ട്രാഫിക് അവസാനിപ്പിക്കുന്നു: അത് കണക്ഷൻ സ്വീകരിച്ച് പിന്നീട് സ്വന്തം മുകളിലേക്കുള്ള കണക്ഷൻ തുറക്കുന്നു. ആ ക്രമീകരണത്തിൽ ഒരു അഭ്യർത്ഥനയ്ക്ക് രണ്ട് കണക്ഷനുകൾ ഉണ്ട്, അവ തമ്മിലുള്ള ബന്ധം പ്രോക്സിയുടെ സ്വന്തം രേഖകളിൽ മാത്രം നിലനിൽക്കുന്നു. ഇവയിൽ ഏതാണ് നിങ്ങൾ വിന്യസിച്ചതെന്ന് അറിയുന്നത് കേർണലിന്റെ ഫ്ലോ അവസ്ഥ വായിക്കണോ ആപ്ലിക്കേഷൻ ലോഗുകൾ വായിക്കണോ എന്ന് തീരുമാനിക്കുന്നു.

മിക്ക ആശയക്കുഴപ്പവും ഊഹത്തിൽ നിന്ന് വരുന്നു. ഉപകരണം തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് രൂപം സ്ഥിരീകരിക്കുക. ആദ്യം സെർവർ കോൺഫിഗറേഷനിൽ പ്രോക്സി നിർദ്ദേശം ഉണ്ടോ എന്ന് വായിക്കുക, കാരണം അതിന്റെ സാന്നിധ്യം തുടർന്നുള്ള ഓരോ ഘട്ടത്തെയും മാറ്റുന്നു. അതില്ലാതെ പാക്കറ്റുകളുടെ പാത റൂട്ടിംഗ് ആണ്, കേർണലിന്റെ ഫ്ലോ അവസ്ഥയാണ് നിങ്ങളുടെ തെളിവ്.

ആദ്യം വിലാസം ഒരു സെഷനുമായി ബന്ധിപ്പിക്കുക

സെർവറിന്റെ സെഷൻ അവസ്ഥയിൽ നിന്ന് ആരംഭിച്ച് ക്ലയന്റിന്റെ നിലവിലെ ആന്തരിക വിലാസം തിരിച്ചറിയുക. പൂളിലെ വിലാസങ്ങൾ പുനരുപയോഗിക്കുന്നു, അതിനാൽ വിലാസം ഒറ്റയ്ക്ക് ഒരു പാട്ടമാണ്, വ്യക്തിയല്ല.

സമയവും പ്രാമാണീകരിച്ച ഐഡന്റിറ്റിയും ഒരുമിച്ച് രേഖപ്പെടുത്തുക, ആ ക്ലയന്റിന് പിന്നിൽ ഒരു മുഴുവൻ ലാൻ ഒളിഞ്ഞിരിക്കുന്നുണ്ടോ എന്ന് ശ്രദ്ധിക്കുക. വിദൂര അറ്റം ഒരു സബ്നെറ്റ് റൂട്ട് ചെയ്യുന്നുവെങ്കിൽ, നിങ്ങൾ കാണുന്ന ആന്തരിക വിലാസങ്ങൾ യഥാർത്ഥ ഹോസ്റ്റുകളോ വിവർത്തനം ചെയ്തവയോ ആകാം.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

ആ ജോടി ഒരേസമയം രണ്ട് ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു: ടണൽ ഇന്റർഫേസ് ഏത് പ്രിഫിക്സ് സേവിക്കുന്നു, നിങ്ങൾക്ക് പ്രധാനമായ ഇടവേളയിൽ ഏത് സെഷൻ സജീവമായിരുന്നു. ഏതെങ്കിലും ഫ്ലോ എൻട്രി വ്യാഖ്യാനിക്കുന്നതിന് മുമ്പ് ഇത് ചെയ്യുക, കാരണം തെറ്റായ സെഷനോട് ബന്ധിപ്പിച്ച ബോധ്യപ്പെടുത്തുന്ന ട്യൂപ്പിൾ ഒരു തെളിവും ഇല്ലാത്തതിനേക്കാൾ മോശമാണ്.

റൂട്ടിംഗ് ഗേറ്റ്വേയിൽ ഫ്ലോ പട്ടിക വായിക്കുക

വിലാസവും ഇടവേളയും സ്ഥാപിച്ചതിന് ശേഷം, ട്രാക്ക് ചെയ്ത കണക്ഷനുകളുടെ വായിക്കാൻ മാത്രമുള്ള പട്ടിക ഗേറ്റ്വേ അതിനായി എന്താണ് കൈമാറുന്നതെന്ന് കാണിക്കുന്നു. മുഴുവൻ പട്ടികയും വായിക്കാതിരിക്കാൻ യഥാർത്ഥ സ്രോതസ്സിൽ ഫിൽട്ടർ ചെയ്യുക.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

ഓരോ എൻട്രിയിലും രണ്ട് ട്യൂപ്പിളുകൾ ഉണ്ട്, യഥാർത്ഥവും മറുപടിയും, അവ ഒരു ഫ്ലോയുടെ രണ്ട് ദിശകളാണ്, രണ്ട് ആപ്ലിക്കേഷനുകളല്ല. സ്രോതസ്സ് NAT പാതയിൽ യഥാർത്ഥ ട്യൂപ്പിൾ ടണലിന്റെ വിലാസം നിലനിർത്തുന്നു, മറുപടി ഭാഗം വിവർത്തനം ചെയ്ത ഗേറ്റ്വേ വിലാസം കാണിക്കുന്നു, അതുകൊണ്ടാണ് ഔട്ട്പുട്ട് ആദ്യ കാഴ്ചയിൽ തെറ്റായി തോന്നുന്നത്.

പട്ടികയെ ചരിത്രമായല്ല, ജീവനുള്ള അവസ്ഥയായി കാണുക. ചെറിയ ഫ്ലോകൾ ഇതിനകം കാലഹരണപ്പെട്ടിരിക്കാം, ട്രാക്ക് ചെയ്യാത്ത ട്രാഫിക് ഒരിക്കലും പ്രത്യക്ഷപ്പെടുന്നില്ല, മറ്റൊരു നെറ്റ്വർക്ക് നെയിംസ്പേസ് മറ്റൊരു പട്ടിക കാണിക്കുന്നു. conntrack റഫറൻസ് ഫിൽട്ടറുകളും ഇരുദിശാ ഔട്ട്പുട്ടും രേഖപ്പെടുത്തുന്നു.

വായന സ്ഥിരീകരിക്കാൻ ഒരു പരിമിത ക്യാപ്ചർ

നിങ്ങൾ നോക്കുന്നിടത്ത് ടണൽ ഇന്റർഫേസ് ദൃശ്യമാണെങ്കിൽ, ഒരു പരിമിത ക്യാപ്ചർ നിങ്ങൾ തിരിച്ചറിഞ്ഞ പാക്കറ്റുകൾ വയറിലുള്ളവയാണോ എന്ന് തീരുമാനിക്കുന്നു. ഫിൽട്ടർ ഇടുങ്ങിയതും പാക്കറ്റ് പരിധി ചെറുതും ആക്കി നിർത്തുക.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

ടൈംസ്റ്റാമ്പുകൾ, പ്രോട്ടോക്കോൾ, പോർട്ടുകൾ എന്നിവ ഫ്ലോ എൻട്രിയുമായും പരിശോധനയായി നടത്തിയ അഭ്യർത്ഥനയുമായും താരതമ്യം ചെയ്യുക. NAT-ന് ശേഷം എടുത്ത ക്യാപ്ചർ ഗേറ്റ്വേയുടെ പൊതു വിലാസം മാത്രം കാണിക്കുന്നു, ടണൽ ഭാഗം ഇപ്പോഴും ക്ലയന്റിന്റേത് കാണിച്ചേക്കാം, ആ വ്യത്യാസം വിവരമാണ്, പൊരുത്തക്കേടല്ല.

ഇന്റർഫേസ് ഒന്നും കാണുന്നില്ലെങ്കിൽ, ക്ലയന്റ് നിഷ്ക്രിയമാണെന്ന് അനുമാനിക്കുന്നതിന് മുമ്പ് ഡാറ്റ പാത പരിശോധിക്കുക: ക്ലയന്റ് തമ്മിലുള്ള ട്രാഫിക്കും ചില ഓഫ്ലോഡ് പാതകളും നിങ്ങൾ നിരീക്ഷിക്കുന്ന പോയിന്റിലൂടെ ഒരിക്കലും കടക്കുന്നില്ല.

പ്രോക്സി ലോഗുകൾ, നിങ്ങൾ കണ്ടതിന്റെ പരിധികൾ

പ്രോക്സി പാതയിലുണ്ടാകുമ്പോൾ, അതിന്റെ മുകളിലേക്കുള്ള സോക്കറ്റുകൾ സോക്കറ്റ് പട്ടികയിൽ ദൃശ്യമാണ്, പക്ഷേ അവ VPN ക്ലയന്റുകളുമായി ഒന്നിനൊന്ന് പൊരുത്തപ്പെടുന്നില്ല, പ്രത്യേകിച്ച് പൂളിംഗ് അല്ലെങ്കിൽ മൾട്ടിപ്ലക്സിംഗിനൊപ്പം. ക്ലയന്റ് ഐഡന്റിറ്റി, ലക്ഷ്യം, ടൈംസ്റ്റാമ്പ്, അത് രേഖപ്പെടുത്തുന്ന ഏതെങ്കിലും അഭ്യർത്ഥന ഐഡന്റിഫയർ എന്നിവ പരസ്പരം ബന്ധിപ്പിക്കാൻ പ്രോക്സിയുടെ കോൺഫിഗർ ചെയ്ത ഇടപാട് ലോഗ് ഉപയോഗിക്കുക.

ഓരോ അഭ്യർത്ഥനയും സ്വതവേ ലോഗ് ചെയ്യുന്നു എന്ന് അനുമാനിക്കുന്നതിന് പകരം വിന്യസിച്ച പതിപ്പിന്റെ ലോഗിംഗ് കോൺഫിഗറേഷൻ പരിശോധിക്കുക.

അവസാനമായി, പരിധിയെക്കുറിച്ച് കൃത്യത പാലിക്കുക. ലക്ഷ്യ വിലാസവും പോർട്ടും മെറ്റാഡാറ്റയാണ്, URL അല്ല, പേജ് ഉള്ളടക്കവുമല്ല, കാരണം ആന്തരിക HTTPS സെഷൻ ടണൽ പരിഗണിക്കാതെ സ്വന്തം സംരക്ഷണം നിലനിർത്തുന്നു. നിങ്ങൾ എന്താണ് നിരീക്ഷിച്ചത്, ഏത് നിരീക്ഷണ പോയിന്റിൽ നിന്ന്, ഏത് സമയത്ത് എന്ന് റിപ്പോർട്ട് ചെയ്യുക.