மார்க் அடிப்படையிலான VPN ஃபயர்வால் தடுக்கும் libvirt விருந்தினர் DNS-ஐ சரிசெய்வது
மார்க் அடிப்படையிலான VPN ஃபயர்வால் ஒரு வடிகட்டி சங்கிலி பார்க்கும் முன்பே விருந்தினர் DNS-ஐ நீக்கிவிடும். mangle முன்னுரிமையில் உள்ள ஒரு விதி வினவலையும் அதன் பதிலையும் குறிக்கும், உங்கள் LAN-ஐ திறக்காமல்.
இயல்புநிலை 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 வரி பிந்தைய எந்தச் சங்கிலியில் சேர்த்தாலும் அந்தப் பாக்கெட்டுக்கு ஒருபோதும் கருதப்படுவதில்லை, அதனால்தான் வெளிப்படையான விதி சரியாகத் தெரிகிறது, ஆனால் எதையும் மாற்றுவதில்லை.
ஏதாவது வேலை செய்யும் வரை அதை விரிவாக்குவது இரண்டாவது பொறி. ஹோஸ்ட்டின் input பாதையில் முழு 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 வரை கட்டுப்படுத்துவது அந்தத் துளையை மற்ற ஒவ்வொரு உள்ளூர் சப்நெட்டிலிருந்தும் விலக்கி வைக்கிறது, அந்த மூலத்துக்கு எதிரான வினவல்களை எண்ணுவது அச்சுறுத்தல் உங்களுக்கு முக்கியம் என்றால் மலிவானது.
மறுதொடக்கத்திலும் நிலைத்திருக்கச் செய்து இரு பகுதிகளையும் நிரூபியுங்கள்
shell கட்டளையில் தட்டச்சு செய்யப்பட்ட விதி அடுத்த துவக்கத்தில் மறைந்துவிடும், VPN இடைமுகம் ஏற்கனவே போக்குவரத்தைக் கடத்திய பிறகு ஏற்றப்படும் விதி முதல் இணைப்பிலேயே பந்தயத்தை இழக்கும். அட்டவணையை ஹோஸ்ட்டின் நிலையான nftables உள்ளமைவில் வையுங்கள், அல்லது VPN சேவைக்கு முன் வரிசைப்படுத்தப்பட்ட யூனிட்டில் வையுங்கள், வரிசையை ஊகிக்காமல் சரிபார்க்கவும்.
சரிபார்ப்புக்கு மூன்று தனித்தனி பதில்கள் தேவை. சங்கிலி ஏற்றப்பட்டு முதலில் வரிசைப்படுத்தப்பட்டுள்ளதை உறுதிப்படுத்துங்கள், conntrack பதிவு இரு திசைகளிலும் மார்க்கைக் காட்டுவதை உறுதிப்படுத்துங்கள், விருந்தினர் தேடல் ஒரு முகவரியைத் திருப்பித் தருவதை உறுதிப்படுத்துங்கள். பிறகு மறுபகுதியை உறுதிப்படுத்துங்கள்: பாதை இறங்கியிருக்கும்போது அல்லது தடுக்கும்போது பொது ஹோஸ்ட்டுக்கான சாதாரண விருந்தினர் இணையப் போக்குவரத்து இன்னும் தோல்வியடைகிறது. DNS வேலை செய்து மற்ற எல்லாம் கசிந்தால், உங்கள் விதி மேலே உள்ளதை விட அகலமானது.
மார்க் வைத்த பிறகும் தேடல்கள் தோல்வியடைந்தால், மூலத்தை விரிவாக்கும் ஆசையை அடக்குங்கள். dnsmasq எங்கு அனுப்புகிறது, விருந்தினரின் தீர்வாக்கி 192.168.122.1 ஐ நோக்குகிறதா அல்லது யாரோ தட்டச்சு செய்த பொது முகவரியை நோக்குகிறதா, வினவல் ஹோஸ்ட்டை அடைகிறதா என்பதைச் சரிபார்க்கவும். குறியிடுவது பாக்கெட்டை உள்ளே விடும், வேறொன்றையும் அல்ல, எனவே மோசமான மேல்நிலை அல்லது உடைந்த மெய்நிகர் நெட்வொர்க் எத்தனை விதிகள் சேர்த்தாலும் உடைந்தே இருக்கும்.