കിൽ സ്വിച്ച് ഏതെങ്കിലും ട്രാഫിക് ഒഴുകുന്നതിന് മുൻപ് VPN സെർവറിനെ തടയുന്നു
കിൽ സ്വിച്ച് ഏത് ഘട്ടത്തെ തടയുന്നു: എൻഡ്‌പോയിന്റ് തിരയൽ, പുറം റൂട്ട്, തിരിച്ചുള്ള വഴി, പഴയ പിയർ ഒഴിവുകൾ — ഊഹങ്ങൾക്കു പകരം കൗണ്ടറുകൾ ഉപയോഗിച്ച്.
കിൽ സ്വിച്ചുകൾ ആളുകൾ പ്രതീക്ഷിക്കാത്ത ദിശയിൽ പരാജയപ്പെടുന്നു: ടണൽ താഴെയിരിക്കുമ്പോൾ ട്രാഫിക് തടയാൻ അവ നിർമ്മിച്ചവയാണ്, ടണൽ നിർമ്മിക്കുന്ന പാക്കറ്റുകൾ തന്നെ ട്രാഫിക്കാണ്. ഇതാണ് മുഴുവൻ കുറ്റം. ടണലിലൂടെ പുറത്തുപോകാത്ത എല്ലാം ഉപേക്ഷിക്കുന്ന നിയമക്കൂട്ടം ടണൽ ഉയർത്തേണ്ട ഹാൻഡ്‌ഷേക്കും ഉപേക്ഷിക്കുന്നു, അതിനാൽ ക്ലയന്റ് ലൂപ്പിൽ വീണ്ടും ശ്രമിക്കുന്നു, പിശക് ആദ്യം പരിശോധിക്കുന്ന ഘട്ടത്തിന് കൊടുക്കുന്നു. ഫയർവാൾ വിശാലമാക്കുന്നതിന് മുൻപ് മൂന്ന് ഘട്ടങ്ങളിൽ ഏതാണ് നിരസിക്കപ്പെടുന്നതെന്ന് കണ്ടെത്തുക: പേരിന്റെ തിരയൽ, പിയറിലേക്കുള്ള പുറം പാക്കറ്റ്, അല്ലെങ്കിൽ തിരിച്ചുവരുന്ന മറുപടി.
ടണലും അതിന്റെ സ്വന്തം ഗതാഗതവും പരസ്പരം എങ്ങനെ ആശ്രയിക്കുന്നു
VPN ക്ലയന്റിനെ ഒരേ സോക്കറ്റ് പാത പങ്കിടുന്ന രണ്ട് നെറ്റ്‌വർക്ക് അവസ്ഥകളായി വായിക്കുക. ടണൽ ഉണ്ടാകുന്നതിന് മുൻപ് ക്ലയന്റ് ഭൗതിക അഡാപ്റ്ററിൽ സോക്കറ്റ് തുറന്ന് എൻക്രിപ്റ്റ് ചെയ്ത ഫ്രെയിമുകൾ പിയറിന്റെ വിലാസത്തിലേക്കും പോർട്ടിലേക്കും അയയ്ക്കുന്നു. ആ കൈമാറ്റം വിജയിച്ചതിനുശേഷം മാത്രമാണ് ടണൽ ഉപകരണം സൃഷ്ടിച്ച് റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നത്. കിൽ സ്വിച്ച് രണ്ടാം അവസ്ഥയെക്കുറിച്ചുള്ള നയമാണ്, രണ്ടിനും ബാധകമാകുന്നത്ര വിശാലമായി എഴുതിയത്.
ഇന്റർഫേസ് അടിസ്ഥാനമാക്കിയ നിയമങ്ങളാണ് സാധാരണ രൂപം: ഇതിലൂടെ പുറത്തുപോകുന്നത് സ്വീകരിക്കുക tun0 അല്ലെങ്കിൽ wg0, ബാക്കിയുള്ള ഔട്ട്‌പുട്ട് പാത ഉപേക്ഷിക്കുക. ഈ രൂപീകരണത്തിന് ക്ലയന്റിന്റെ സ്വന്തം സെർവർ ബന്ധം ഒഴിവാക്കാനാകില്ല, അതിനാൽ ശരിയായ നടപ്പാക്കൽ ആ ഒഴിവ് വ്യക്തമായി ചേർക്കുന്നു, കൈകൊണ്ട് നിയമങ്ങൾ എഴുതുമ്പോൾ നിങ്ങളും അങ്ങനെ ചെയ്യുന്നു. Windows, macOS എന്നിവയിൽ ആപ്ലിക്കേഷൻ അനുസരിച്ചുള്ള നിയമങ്ങൾ ഇന്റർഫേസിനു പകരം പ്രോസസ് പൊരുത്തപ്പെടുത്തി ഇതിന്റെ ഒരു ഭാഗം ഒഴിവാക്കുന്നു, പക്ഷേ ടണൽ ഉണ്ടാകുന്നതിന് മുൻപ് പ്രോസസും പുറത്തുപോകണം.
മൂന്ന് ഘട്ടങ്ങൾ, അവ സംഭവിക്കുന്ന ക്രമത്തിൽ
ആദ്യ ഘട്ടം പരിഹാരമാണ്. പ്രൊഫൈൽ അക്ഷരാർത്ഥ വിലാസത്തിനു പകരം ഹോസ്റ്റ്‌നെയിം സൂക്ഷിക്കുമ്പോൾ, എന്തെങ്കിലും അയയ്ക്കുന്നതിന് മുൻപ് ക്ലയന്റിന് DNS മറുപടി വേണം. DNS-നെ ടണലിന്റെ റിസോൾവറിലേക്ക് തിരിക്കുന്ന പ്രൊഫൈൽ ഒരു കുടുക്ക് സൃഷ്ടിക്കുന്നു: തിരയൽ സജീവമാക്കേണ്ട ടണലിലൂടെ മാത്രമേ റിസോൾവറിൽ എത്താനാകൂ. ടണലിന് പുറത്ത് പരിഹരിക്കുന്നതോ എൻഡ്‌പോയിന്റ് ഒരു വിലാസത്തിൽ പിന്നിടുന്നതോ ഈ ആശയക്കുഴപ്പം നീക്കുന്നു.
രണ്ടാം ഘട്ടം പുറം പാക്കറ്റാണ്, അത് ഈ ക്രമത്തിൽ ആദ്യം റൂട്ടിംഗും പിന്നീട് ഫയർവാളും കടക്കണം. wireguard-tools WireGuard-നായി ഇതിന്റെ റൂട്ടിംഗ് പകുതി കൈകാര്യം ചെയ്യുന്നു: സ്വന്തം പാക്കറ്റുകൾ അടയാളപ്പെടുത്തി, ഇപ്പോൾ ഇൻസ്റ്റാൾ ചെയ്ത ഡിഫോൾട്ട് റൂട്ട് ഒഴിവാക്കാൻ ഒരു നയ നിയമം ചേർക്കുന്നു; wg-quick മാനുവൽ പേജ് ആ നിയമവും ഉപയോഗിക്കുന്ന പട്ടികയും വിവരിക്കുന്നു. ആ റൂട്ടിംഗ് കൈകൊണ്ട് വീണ്ടും നിർമ്മിക്കുക, അല്ലെങ്കിൽ രണ്ടാമത്തെ ഉപകരണത്തെ നിയമങ്ങൾ വീണ്ടും എഴുതാൻ അനുവദിക്കുക, അടയാളപ്പെടുത്തിയ പാക്കറ്റുകൾ അവ സൃഷ്ടിക്കേണ്ട ടണലിലേക്ക് തിരികെ അയയ്ക്കാം.
മൂന്നാം ഘട്ടം തിരിച്ചുള്ള വഴിയാണ്. മറുപടിയില്ലാത്ത ഹാൻഡ്‌ഷേക്ക് പുറത്തേക്കുള്ള ഉപേക്ഷയുടെ തെളിവല്ല; അത് സെർവറിന്റെ ഇൻബൗണ്ട് നിയമവുമായോ മാപ്പിംഗ് മറന്ന NAT ഉപകരണവുമായോ ഒരുപോലെ യോജിക്കുന്നു. ക്ലയന്റിനെ തൊടുന്നതിന് മുൻപ് ഇവ വേർതിരിക്കുക.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
ക്ലയന്റുകൾ കണ്ടെത്തുന്ന ലക്ഷണം രേഖപ്പെടുത്തുന്നു, പരാജയപ്പെട്ട ഘട്ടമല്ല, അതിനാൽ പട്ടിക സാധാരണയായി ലോഗിനേക്കാൾ വേഗതയുള്ളതാണ്.
കൗണ്ടറുകൾ ലോഗുകളേക്കാൾ വേഗം തീരുമാനിക്കുന്നു
Linux-ൽ, nft list ruleset അല്ലെങ്കിൽ iptables -vnL OUTPUT ഓരോ നിയമത്തിനും ഒരു പാക്കറ്റ് കൗണ്ടർ പ്രിന്റ് ചെയ്യുന്നു. ഒരിക്കൽ കണക്റ്റ് ചെയ്യുക, പരാജയപ്പെടാൻ അനുവദിക്കുക, പിന്നീട് കൗണ്ടറുകൾ വീണ്ടും വായിക്കുക. കൗണ്ടർ നീങ്ങിയ നിയമമാണ് ഹാൻഡ്‌ഷേക്ക് കൊണ്ട നിയമം; എവിടെയും ഒന്നും നീങ്ങിയില്ലെങ്കിൽ പാക്കറ്റ് ഒരിക്കലും ഫയർവാളിൽ എത്തിയില്ല. ഒരു നിയമക്കൂട്ടം സ്വന്തം ഹാൻഡ്‌ഷേക്ക് ഉപേക്ഷിക്കുന്നത് ഞാൻ കണ്ടിട്ടുണ്ട്, അത് പറഞ്ഞത് കൗണ്ടറുകൾ മാത്രമാണ്.
ഒരിക്കലും ഫയർവാളിൽ എത്തിയില്ല എന്നതിനെ ഒരിക്കലും ഹോസ്റ്റ് വിട്ടില്ല എന്നതിൽ നിന്ന് വേർതിരിക്കാൻ ഇന്റർഫേസ് തന്നെ നിരീക്ഷിക്കുക. ip -s link show dev wlan0 അയച്ച പാക്കറ്റുകൾ റിപ്പോർട്ട് ചെയ്യുന്നു, tcpdump -ni wlan0 udp port 51820 ഫ്രെയിമുകൾ കാണിക്കുന്നു. ക്ലയന്റ് വീണ്ടും ശ്രമിക്കുമ്പോൾ അത് പരന്നു നിൽക്കുന്നുവെങ്കിൽ, തകരാർ netfilter-ന് മുകളിലാണ്: കാണാത്ത പിയർ റൂട്ട്, ഇപ്പോഴും ഇല്ലാത്ത ഉപകരണത്തിലേക്ക് ചൂണ്ടുന്ന നയ നിയമം, അല്ലെങ്കിൽ ക്ലയന്റ് വിഴുങ്ങുന്ന സോക്കറ്റ് പിശക്.
ഒഴിവുകൾ ഡോക്യുമെന്റേഷൻ വിലാസങ്ങളിൽ പരീക്ഷിക്കുക, ഉദാഹരണത്തിന് 203.0.113.10, ഒരു വീഴ്ച മറ്റൊരാളുടെ ഹോസ്റ്റ് പരിശോധിക്കാതിരിക്കാൻ.
പഴയ എൻഡ്‌പോയിന്റ് ഒഴിവ് സെർവർ തകർന്നതുപോലെ വായിക്കപ്പെടുന്നു
ഏറ്റവും തെറ്റിദ്ധരിപ്പിക്കുന്ന പതിപ്പ് പിയറിന്റെ വിലാസം മാറിയതിനുശേഷം പ്രത്യക്ഷപ്പെടുന്നു: ചലനാത്മക വിലാസ സേവനം അത് നീക്കി, ഹോസ്റ്റ് വീണ്ടും നിർമ്മിച്ചു, അല്ലെങ്കിൽ നിങ്ങളുടെ നെറ്റ്‌വർക്കിന്റെ പുറം വിലാസം വ്യത്യസ്തമാണ്. ഒഴിവ് ഇപ്പോഴും പഴയ വിലാസം പേരിടുന്നു, അതിനാൽ പുതിയതിലേക്കുള്ള പാക്കറ്റുകൾ ഉപേക്ഷിക്കുന്ന നിയമത്തിൽ വീഴുന്നു. അതേ കോൺഫിഗറേഷൻ ഇന്നലെ പ്രവർത്തിച്ചിരുന്നു, അതുകൊണ്ടാണ് ആളുകൾ സെർവർ പരിശോധിച്ച് തുടങ്ങുന്നത്.
ഫയർവാൾ നിയമത്തിനുള്ളിലെ ഹോസ്റ്റ്‌നെയിം നിങ്ങളെ രക്ഷിക്കുന്നില്ല. nftables-ൽ നിയമക്കൂട്ടം ലോഡ് ചെയ്യുമ്പോൾ പേര് പരിഹരിക്കപ്പെടുന്നു, അതിനാൽ ആ നിമിഷം ഉണ്ടായിരുന്ന വിലാസം അത് പിന്നിടുന്നു, അക്ഷരാർത്ഥ വിലാസം പോലെ പഴകുന്നു. ശാശ്വതമായ പരിഹാരം എൻഡ്‌പോയിന്റ് മാറുമ്പോൾ ഒഴിവ് പുതുക്കുകയും അത് ഇടുങ്ങിയതായി സൂക്ഷിക്കുകയുമാണ്: ഒരു പിയർ വിലാസം, ഒരു ഗതാഗത പോർട്ട്. വിലാസ മാറ്റം അതിജീവിക്കാനുള്ളത്ര വിശാലമായ ശ്രേണി ബന്ധമില്ലാത്ത ട്രാഫിക്കും പുറത്തുപോകാൻ അനുവദിക്കാനുള്ളത്ര വിശാലമാണ്.
കിൽ സ്വിച്ച് സെർവർ ഹോസ്റ്റിൽ പ്രവർത്തിക്കുമ്പോൾ
അതേ ആശ്രിതത്വം മറുവശത്തുമുണ്ട്, അവിടെ അത് വിട്ടുപോകാൻ എളുപ്പമാണ്. നിങ്ങളുടെ VPN സെർവറായി പ്രവർത്തിക്കുന്ന യന്ത്രം കിൽ സ്വിച്ചുള്ള ഡെസ്ക്ടോപ്പ് ക്ലയന്റോ ലാപ്ടോപ്പിൽ നിന്ന് പകർത്തിയ ഫയർവാൾ പ്രൊഫൈലോ പ്രവർത്തിപ്പിക്കുന്നുവെങ്കിൽ, അതിന്റെ ഉപേക്ഷിക്കൽ നിയമങ്ങൾ ടണലുകൾ അവസാനിപ്പിക്കുന്ന സേവനത്തിന് ബാധകമാണ്. ക്ലയന്റിന്റെ ഹാൻഡ്‌ഷേക്കിനുള്ള മറുപടികൾ ഉപേക്ഷിക്കപ്പെടുന്നു, അതിനാൽ സെർവർ ആരോഗ്യകരമായി കാണപ്പെടുകയും അതിന്റെ ടണൽ ഇന്റർഫേസ് ഉപയോഗിക്കാതെ കിടക്കുകയും ചെയ്യുമ്പോഴും ഓരോ ക്ലയന്റും കണക്റ്റ് ചെയ്യാൻ പരാജയപ്പെടുന്നു.
ആ ഹോസ്റ്റിന് ഉപേക്ഷിക്കുന്നതിന് മുൻപ് മൂന്ന് ഇടുങ്ങിയ സ്വീകരണങ്ങൾ വേണം: ഭൗതിക ഇന്റർഫേസിലെ കേൾക്കുന്ന പോർട്ട്, ഡീക്രിപ്റ്റ് ചെയ്ത ട്രാഫിക്കിനുള്ള ടണൽ ഇന്റർഫേസ്, ടണലിൽ നിന്ന് ക്ലയന്റുകൾ എത്തേണ്ടയിടത്തേക്കുള്ള ഫോർവേഡിംഗ്. ഇൻസ്റ്റാൾ ചെയ്ത കൂട്ടം ഇതുകൊണ്ട് വായിക്കുക: nft list ruleset, iptables -S, അല്ലെങ്കിൽ pfctl -sr എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ്, സംരക്ഷിച്ച നിയമക്കൂട്ടം റീബൂട്ടിനെ അതിജീവിക്കുന്നു എന്ന് ഓർക്കുക, അതിനാൽ അവിടത്തെ തെറ്റ് അത് ഉണ്ടാക്കിയ പ്രോസസിനെക്കാൾ കൂടുതൽ കാലം ജീവിക്കുന്നു.
യന്ത്രത്തെ അടച്ചുനിർത്തുന്ന വീണ്ടെടുപ്പ് ക്രമം
പ്രൊഫൈലിൽ നിന്ന് പുറത്തേക്ക് പ്രവർത്തിക്കുക. ക്ലയന്റ് ഉപയോഗിക്കുന്ന പിയർ വിലാസവും പോർട്ടും വായിക്കുക, ടണലില്ലാതെ ഹോസ്റ്റ്‌നെയിം പരിഹരിക്കപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക, പിന്നീട് ഭൗതിക അഡാപ്റ്ററിൽ മാത്രം ആ വിലാസത്തിനും പോർട്ടിനും ഒരു ഒഴിവ് ചേർക്കുക. വീണ്ടും കണക്റ്റ് ചെയ്ത് അയയ്ക്കൽ കൗണ്ടർ നിരീക്ഷിക്കുക; പൂർത്തിയായ ഹാൻഡ്‌ഷേക്കാണ് രണ്ടാം ഘട്ടം ശരിയായി എന്നതിന്റെ സൂചന.
പരീക്ഷിക്കുമ്പോൾ ബാക്കിയുള്ള ഉപേക്ഷിക്കൽ നയം അതിന്റെ സ്ഥാനത്ത് വിടുക. നിരുപദ്രവ പരിശോധന എന്നത് ബന്ധമില്ലാത്ത ഡോക്യുമെന്റേഷൻ വിലാസത്തിലേക്ക് കണക്ഷൻ ശ്രമിച്ച് അത് ഇപ്പോഴും സമയപരിധിയിൽ അവസാനിക്കുന്നുവെന്ന് ഉറപ്പാക്കുന്നതാണ്, ഇത് കിൽ സ്വിച്ച് ഓഫാണെന്നല്ല, പ്രവർത്തിക്കുന്നുവെന്ന് കാണിക്കുന്നു. ടണൽ സ്ഥിരതയാർന്നാൽ ഒഴിവ് കർശനമാക്കുക, സൗകര്യമാണെന്ന് പറഞ്ഞ് ക്ലയന്റ് പ്രോഗ്രാമിന് സ്ഥിരമായ എല്ലാം-അനുവദം വിടരുത്.
ടണൽ ഉയർന്നിട്ടും ആപ്ലിക്കേഷൻ പരാജയപ്പെടുന്നുവെങ്കിൽ, ബാക്കിയുള്ള ഘട്ടങ്ങൾ ഇതല്ല: വിഭജിത DNS, MTU, ഓരോ ആപ്ലിക്കേഷനുള്ള റൂട്ടിംഗ് എന്നിവ ഓരോന്നും ബന്ധിപ്പിച്ച ടണലും തകർന്ന ട്രാഫിക്കും നൽകുന്നു, ഓരോന്നിനും വ്യത്യസ്തമായ ആദ്യ പരിശോധനയുണ്ട്.