libvirt അതിഥിയുടെ DNS മാർക്ക് അടിസ്ഥാനമാക്കിയ VPN ഫയർവാൾ തടയുന്നത് ശരിയാക്കുക

സ്ഥിരസ്ഥിത libvirt നെറ്റ്വർക്കിലെ അതിഥികൾ WireGuard ഇന്റർഫേസ് ഉയരുന്നതുവരെ പേരുകൾ തികച്ചും പരിഹരിക്കുന്നു, പിന്നീട് ഓരോ തിരയലും അതേ സ്ഥലത്ത് നിലയ്ക്കുന്നു. dnsmasq ഇപ്പോഴും 192.168.122.1:53 ൽ കേൾക്കുന്നു, അതിഥിക്ക് ഇപ്പോഴും ആ വിലാസം റിസോൾവർ ആയി ഉണ്ട്, ക്വറിയും ഇപ്പോഴും എത്തുന്നു. മാറിയത് എന്തെന്നാൽ ഹോസ്റ്റിന്റെ സ്വന്തം അപ്സ്ട്രീം ക്വറി, അല്ലെങ്കിൽ അതിനുള്ള ഉത്തരം, ഇപ്പോൾ നിങ്ങൾ തിരുത്താൻ ചിന്തിക്കാവുന്ന ഏത് ഫിൽട്ടർ ശൃംഖലയ്ക്കും മുമ്പ് വിലയിരുത്തപ്പെടുന്ന ഒരു നിയമത്താൽ ഉപേക്ഷിക്കപ്പെടുന്നു. പുറത്തുകടക്കാനുള്ള വഴി ഉത്തരം പാരമ്പര്യമായി ലഭിക്കുന്ന കണക്ഷനിൽ മതിയായ നേരത്ത് പ്രയോഗിക്കുന്ന മാർക്ക് ആണ്.

ടണൽ ഉയരുന്ന നിമിഷം അതിഥികൾ DNS നഷ്ടപ്പെടുത്തുന്നു

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് രൂപം സ്ഥിരീകരിക്കുക. ടണൽ താഴ്ത്തുക, അതിഥിയിൽ നിന്ന് dig @192.168.122.1 example.com പ്രവർത്തിപ്പിക്കുക, അത് ഉത്തരം നൽകുന്നത് കാണുക. ടണൽ ഉയർത്തുക, ആവർത്തിക്കുക, സമയം കഴിയുന്നത് കാണുക. ഈ ജോടി ഫലങ്ങൾ ഒരു ഘട്ടത്തിൽ തകർന്ന libvirt നെറ്റ്വർക്ക്, തെറ്റായ റിസോൾവർ വിലാസം, മരിച്ച dnsmasq എന്നിവ ഒഴിവാക്കുന്നു.

പിന്നീട് ഹോസ്റ്റ് വശം നോക്കുക. dnsmasq ക്വറിയും അതിന്റെ അപ്സ്ട്രീം കൈമാറ്റവും ലോഗ് ചെയ്യുന്നുവെങ്കിൽ പാക്കറ്റ് എത്തി, പരാജയം പുറത്തേക്കുള്ള വഴിയിലാണ്. dnsmasq ഒന്നും ലോഗ് ചെയ്യുന്നില്ലെങ്കിൽ അതിഥിയുടെ ക്വറി പ്രവേശനത്തിൽ ഉപേക്ഷിക്കപ്പെടുന്നു, ഒപ്പം ഈ ലേഖനം മാർക്ക് ചെയ്യുന്ന ഹൂക്കിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു ഹൂക്കിനാണ് ഒഴിവ് അവകാശപ്പെടുന്നത്.

പിന്നീടുള്ള ശൃംഖലയിലെ accept നിയമം ഒരിക്കലും പ്രവർത്തിക്കാത്തത് എന്തുകൊണ്ട്

മാർക്ക് അടിസ്ഥാനമാക്കിയ VPN ഫയർവാൾ പാക്കറ്റ് മാർക്കോ കണക്ഷൻ മാർക്കോ നോക്കിയാണ് തീരുമാനിക്കുന്നത്, നിങ്ങളുടെ ഉറവിട വിലാസമല്ല. പ്രതീക്ഷിച്ച മാർക്ക് ഇല്ലാതെ ഫിസിക്കൽ ഇന്റർഫേസിൽ എത്തുന്നതെല്ലാം നിരസിക്കപ്പെടുന്നു, ആ നിരസിക്കൽ മാർക്ക് പരിശോധന ഉള്ള നിയമക്കൂട്ടത്തിൽ സംഭവിക്കുന്നു. പിന്നീടുള്ള ശൃംഖലയിൽ ചേർത്ത ip saddr 192.168.122.0/24 accept വരി ആ പാക്കറ്റിനായി ഒരിക്കലും പരിഗണിക്കപ്പെടുന്നില്ല, അതുകൊണ്ടാണ് വ്യക്തമായ നിയമം ശരിയെന്ന് തോന്നുന്നതും ഒന്നും മാറ്റാത്തതും.

എന്തെങ്കിലും പ്രവർത്തിക്കുന്നതുവരെ അത് വിശാലമാക്കുന്നത് രണ്ടാമത്തെ കെണിയാണ്. ഹോസ്റ്റിന്റെ ഇൻപുട്ട് പാതയിൽ മുഴുവൻ libvirt സബ്നെറ്റും സ്വീകരിക്കുന്നത് അതിഥികൾക്ക് ഹോസ്റ്റിന്റെ എല്ലാ സേവനങ്ങളും തുറക്കുന്നു, യഥാർത്ഥ ആവശ്യം ഒരു പോർട്ട് മാത്രമായിരിക്കെ.

ഇടുങ്ങിയ ഒഴിവ് സാധ്യമാക്കുന്ന സംവിധാനം കണക്ഷൻ ട്രാക്കിംഗ് ആണ്. ഒരു പാക്കറ്റിൽ ct mark സജ്ജീകരിക്കുമ്പോൾ മൂല്യം പാക്കറ്റിൽ മാത്രമല്ല, conntrack എൻട്രിയിൽ സംഭരിക്കുന്നു, അതിനാൽ ആ കണക്ഷനിലെ ഓരോ പാക്കറ്റും പിന്നീട് അത് വഹിക്കുന്നു, ഹോസ്റ്റിൽ നിന്ന് അതിഥിയിലേക്കുള്ള ഉത്തരവും ഉൾപ്പെടെ. ഇതാണ് മുഴുവൻ തന്ത്രം: അഭ്യർത്ഥന ഒരിക്കൽ മാർക്ക് ചെയ്യുക, മടങ്ങിവരുന്ന പാത ഇതിനകം മാർക്ക് ചെയ്തിട്ടുണ്ട്.

VPN പട്ടിക അത് കാണുന്നതിന് മുമ്പ് ക്വറി മാർക്ക് ചെയ്യുക

ഒഴിവ് അതിന്റേതായ പട്ടികയിൽ വയ്ക്കുക, പിന്നീടുള്ള വായനക്കാരന് VPN നിയമങ്ങൾ വിശകലനം ചെയ്യാതെ അത് കണ്ടെത്താം:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle നെഗറ്റീവ് ആണ്, ഇത് ഈ ശൃംഖലയെ VPN പാക്കേജ് പൂജ്യം മുൻഗണനയിൽ ഇൻസ്റ്റാൾ ചെയ്യുന്ന സാധാരണ ഫിൽട്ടർ ശൃംഖലകൾക്ക് മുന്നിൽ നിർത്തുന്നു. ഹൂക്കുകളുടെ ക്രമമാണ് നിയമത്തെ ഫലപ്രദമാക്കുന്നത്; VPN ശൃംഖലയ്ക്ക് ശേഷം അടുക്കുന്ന ശൃംഖലയിലെ അതേ നിയമം അലങ്കാരം മാത്രമാണ്.

മാർക്ക് നമ്പർ തന്നെ കൈമാറാനാവില്ല. ഇൻസ്റ്റാൾ ചെയ്ത VPN നിയമങ്ങൾ അവയുടെ സ്വന്തം ട്രാഫിക്കിന് സ്വീകരിക്കുന്ന മൂല്യം എടുക്കുക, ജീവനുള്ള നിയമക്കൂട്ടത്തിൽ നിന്ന് വായിക്കുക, അത് ഉപയോഗിക്കുക. തെറ്റായ മാർക്ക് വ്യക്തമായി ലോഡ് ചെയ്യുന്ന, ഓരോ ക്വറിയുമായും പൊരുത്തപ്പെടുന്ന, ഒന്നും അനുവദിക്കാത്ത ഒരു നിയമം ഉണ്ടാക്കുന്നു.

ദ്വാരം പോർട്ട് 53 ന്റെ വീതിയിൽ നിർത്തുക

എഴുതിയിരിക്കുന്നതുപോലെ, ഇത് libvirt സബ്നെറ്റിൽ നിന്ന് ഹോസ്റ്റിലേക്ക് TCP അല്ലെങ്കിൽ UDP പോർട്ട് 53 വഴി DNS അനുവദിക്കുന്നു, മറ്റൊന്നുമില്ല. അതിഥികൾക്ക് ടണലിന് പുറത്തുള്ള ഇന്റർനെറ്റ് എത്താൻ ഇത് അനുവദിക്കുന്നില്ല, ഹോസ്റ്റിന് അതിഥികളിലേക്ക് കണക്ഷനുകൾ തുറക്കാൻ അനുവദിക്കുന്നുമില്ല. അതിഥിക്ക് പിന്നീട് മറ്റൊരു ഹോസ്റ്റ് സേവനം ആവശ്യമായാൽ, ഈ നിയമം അയയ്ക്കുന്നതിന് പകരം ആ ലക്ഷ്യ പോർട്ട് പേരിടുന്ന പ്രത്യേക നിയമം ചേർക്കുക.

നിങ്ങൾ എന്താണ് കൈമാറ്റം ചെയ്യുന്നതെന്നതിൽ സത്യസന്ധരായിരിക്കുക. റിസോൾവറിൽ എത്താൻ കഴിയുന്ന അതിഥിക്ക് DNS ക്വറികൾ വഴി അനിയന്ത്രിത ഡാറ്റയും ടണൽ ചെയ്യാനാകും, ഈ ഒഴിവ് VPN അതിർത്തിയിൽ ബോധപൂർവം ഇട്ട വിടവാണ്, പ്രാദേശിക നെറ്റ്വർക്ക് വിശ്വസനീയമാണെന്ന പ്രസ്താവനയല്ല. ഉറവിടത്തെ 192.168.122.0/24 ആയി പരിമിതപ്പെടുത്തുന്നത് വിടവിനെ മറ്റെല്ലാ പ്രാദേശിക സബ്നെറ്റുകളിൽ നിന്നും ദൂരെ നിർത്തുന്നു, ഭീഷണി നിങ്ങൾക്ക് പ്രധാനമാണെങ്കിൽ ആ ഉറവിടത്തിനെതിരെ ക്വറികൾ എണ്ണുന്നത് വിലകുറഞ്ഞതാണ്.

ഇത് റീബൂട്ടിൽ അതിജീവിക്കാൻ ആക്കുക, രണ്ട് പകുതികളും തെളിയിക്കുക

ഷെൽ പ്രോംപ്റ്റിൽ ടൈപ്പ് ചെയ്യുന്ന നിയമം അടുത്ത ബൂട്ടിൽ അപ്രത്യക്ഷമാകുന്നു, VPN ഇന്റർഫേസ് ഇതിനകം ട്രാഫിക് കടത്തിവിട്ടതിന് ശേഷം ലോഡ് ചെയ്യുന്ന നിയമം ആദ്യ കണക്ഷനിൽ മത്സരം തോൽക്കുന്നു. പട്ടിക ഹോസ്റ്റിന്റെ സ്ഥിരമായ nftables കോൺഫിഗറേഷനിൽ, അല്ലെങ്കിൽ VPN സേവനത്തിന് മുമ്പ് ക്രമീകരിച്ച യൂണിറ്റിൽ വയ്ക്കുക, ക്രമം അനുമാനിക്കാതെ പരിശോധിക്കുക.

പരിശോധനയ്ക്ക് മൂന്ന് വേർതിരിച്ച ഉത്തരങ്ങൾ വേണം. ശൃംഖല ലോഡ് ചെയ്തതും ആദ്യം ക്രമീകരിച്ചതും സ്ഥിരീകരിക്കുക, conntrack എൻട്രി ഇരു ദിശകളിലും മാർക്ക് കാണിക്കുന്നത് സ്ഥിരീകരിക്കുക, അതിഥിയുടെ തിരയൽ വിലാസം തിരികെ നൽകുന്നത് സ്ഥിരീകരിക്കുക. പിന്നീട് മറ്റേ പകുതി സ്ഥിരീകരിക്കുക: പൊതു ഹോസ്റ്റിലേക്കുള്ള അതിഥിയുടെ സാധാരണ വെബ് ട്രാഫിക് ടണൽ താഴെയോ തടയുന്നതോ ആയിരിക്കുമ്പോഴും പരാജയപ്പെടുന്നു. DNS പ്രവർത്തിച്ച് ബാക്കിയെല്ലാം ചോരുകയാണെങ്കിൽ, നിങ്ങളുടെ നിയമം മുകളിലുള്ളതിനേക്കാൾ വിശാലമാണ്.

മാർക്ക് സ്ഥാപിച്ചതിന് ശേഷവും തിരയലുകൾ പരാജയപ്പെടുന്നെങ്കിൽ, ഉറവിടം വിശാലമാക്കാനുള്ള പ്രേരണയെ എതിർക്കുക. dnsmasq എവിടേക്ക് കൈമാറുന്നു, അതിഥിയുടെ റിസോൾവർ 192.168.122.1 ലേക്കാണോ ആരോ ടൈപ്പ് ചെയ്ത പൊതു വിലാസത്തിലേക്കാണോ ചൂണ്ടുന്നത്, ക്വറി ഹോസ്റ്റിൽ എത്തുന്നുണ്ടോ എന്നിവ പരിശോധിക്കുക. മാർക്കിംഗ് പാക്കറ്റ് അനുവദിക്കുന്നു, അതിൽ കൂടുതലൊന്നുമില്ല, അതിനാൽ മോശം അപ്സ്ട്രീം അല്ലെങ്കിൽ തകർന്ന വെർച്വൽ നെറ്റ്വർക്ക് എത്ര നിയമങ്ങൾ ചേർത്താലും തകർന്നു തന്നെയിരിക്കും.