பாதிக்கப்பட்ட ஹோஸ்ட்டில் அவசர சுவிட்ச் எதை மூடுகிறது என்பதை சோதிப்பது எப்படி

அவசர சுவிட்சை இயக்கி, டன்னல் சேவையகத்தை ஆஃப்லைனில் வைத்து, இயந்திரம் இன்னும் என்ன செய்கிறது என்பதைக் கவனியுங்கள்। இந்தச் சோதனை மதிப்புள்ளது, ஏனெனில் ஃபயர்வால் உண்மையில் என்ன நடைமுறைப்படுத்துகிறது என்பதை நீங்கள் கருதியதிலிருந்து பிரிக்கிறது, மேலும் முடிவுகள் பல தயாரிப்புப் பக்கங்கள் குறிப்பிடுவதை விடக் குறுகியவை। அவசர சுவிட்ச் பிணையப் பாதைகளைக் கட்டுப்படுத்துகிறது; சாதனத்தில் ஏற்கனவே இயங்கும் மென்பொருளை அது கட்டுப்படுத்தாது। கிளையண்ட் fail-closed என்று கூறும் ஒவ்வொரு இயந்திரத்திலும் இந்த வரிசையை இயக்குகிறேன், அது சுமார் பத்து நிமிடங்கள் எடுக்கும்।

சேவையகத்திலிருந்து அல்ல, கிளையண்டிலிருந்து தொடங்குங்கள்

செயல்படுத்தும் புள்ளி நீங்கள் அமர்ந்திருக்கும் ஹோஸ்ட்: இயக்க முறைமையின் ஃபயர்வால், ஒரு துணைச் சேவை அல்லது VPN கிளையண்டின் சொந்த இயக்கி। இது முக்கியம், ஏனெனில் சுவிட்ச் செய்யக்கூடிய அனைத்தும் அந்த அடுக்கு பார்ப்பதால் வரையறுக்கப்படுகிறது। கிளையண்ட் தடுப்பை ரூட்டிங் விதி மற்றும் குறியுடன் செயல்படுத்தினால், போதுமான சலுகைகள் உள்ள எதுவும் தனது சொந்த விதியைச் சேர்க்கலாம்; கர்னல் ஃபயர்வால் அட்டவணையைப் பயன்படுத்தினால், அதே சலுகைகள் அட்டவணையைத் திருத்தலாம்। சைஃபரின் வலிமை இந்தக் கேள்விக்குள் ஒருபோதும் வராது।

எனவே முதலில் தீர்மானிக்க வேண்டியது, இந்தச் சாதனத்தின் கொள்கை யாருக்குச் சொந்தம், எதை மீற அனுமதிக்கப்பட்டுள்ளது என்பதுதான்। நிர்வகிக்கப்படும் பணி இயந்திரத்தில் பதில் பொதுவாக நிறுவனத்தின் எண்ட்பாயிண்ட் முகவர், தனிப்பட்ட VPN அந்தத் திறன்களை நீக்காது, டன்னல் எப்படி உள்ளமைக்கப்பட்டாலும்।

முதல் படி: அது மூடுவதாக நீங்கள் நம்பும் பாதைகளில் தடுப்பை உறுதிப்படுத்துங்கள்

கிளையண்டிலல்ல, தொலை முனையில் டன்னலை இறக்குங்கள், அப்போது கிளையண்ட் இன்னும் இணைக்கப்பட்டிருக்க வேண்டும் என்று நம்பும்। பிறகு ஒரு நபர் உண்மையில் முயற்சிக்கும் விஷயத்தை முயற்சியுங்கள்:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

வேகமாகவும் தூய்மையாகவும் தோல்வியடையும் கிளையண்ட் வேண்டும், உலாவியின் நேர வரம்பு வரை தொங்கும் ஒன்றல்ல। தொங்குதல் பொதுவாக மறுப்பு இல்லாத விதியால் பாக்கெட்டுகள் அமைதியாக வீசப்படுவதைக் குறிக்கிறது, அது ஏற்கத்தக்கது, ஆனால் இறந்த இடைமுகத்தை நோக்கிய பழைய இயல்புநிலை வழியை கிளையண்ட் விட்டுச் சென்றிருக்கலாம் என்றும் பொருள்படும்। டன்னல் கீழே இருக்கும்போது ரூட்டிங் அட்டவணையைப் படியுங்கள்: இன்னும் டன்னல் சாதனத்தை நோக்கும் இயல்புநிலை வழியும், புதிய வெளிச்செல் இணைப்புகளை மட்டும் தடுக்கும் ஃபயர்வால் விதியும் வெவ்வேறு நிலைகள், அவற்றில் ஒன்று மட்டுமே fail-closed।

கிளையண்டின் allow-LAN விருப்பம் இயக்கத்திலும் முடக்கத்திலும் அதே கட்டளைகளை மீண்டும் இயக்குங்கள்। அந்த டாகிள்தான் அதிக ஆச்சரியங்களின் இடம், ஏனெனில் மீதமுள்ள கொள்கை மூடுவதற்கு எழுதப்பட்ட பாதையை அது மீண்டும் திறக்கிறது।

இரண்டாம் படி: DNS மற்றும் IPv6 ஐ தனித்தனி பாதைகளாகச் சரிபாருங்கள்

பெயர் தீர்வு என்பது பெரும்பாலான செயலாக்கங்களில் தப்பிப்பிழைக்கும் இடைவெளி, ஏனெனில் வினவல் கணினி தீர்வானிலிருந்து வேறு ஒன்றின் வழியாக வெளியேறலாம்। உங்கள் தீர்வானி உள்ளமைவைப் புறக்கணிக்கும் கருவியுடன் கேளுங்கள், அங்கேயே v6 பக்கத்தையும் சரிபாருங்கள்:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

டன்னல் கீழே இருக்கும்போது இரு பெயர் வினவல்களுக்கும் காலியான பதில்களே நீங்கள் விரும்பும் முடிவு। இரண்டாவது வினவல் பதிலளித்தால், கடினமாக குறியிடப்பட்ட தீர்வானி முகவரி அணுகக்கூடியது, டன்னல் இயந்திரத்திலிருந்து வெளியேறும் ஒரே வழி அல்ல। v6 கோரிக்கை மட்டும் வெற்றியடைந்தால், கொள்கை IPv4 ஐ மூடி IPv6 ஐப் புறக்கணிக்கிறது, அது வேறு முகவரி குடும்பத்தில் அதே கசிவு।

உலாவிகள் இதை வெளியிலிருந்து படிப்பதைக் கடினமாக்குகின்றன, ஏனெனில் DNS over HTTPS க்கு உள்ளமைக்கப்பட்ட உலாவி வினவலை HTTPS கோரிக்கை மூலம் தீர்க்கிறது: அந்த முனைக்கான போர்ட் 443 எவ்வளவு தடுக்கப்பட்டுள்ளதோ அவ்வளவே வினவலும் தடுக்கப்படுகிறது। கொள்கை உள்ளூர் சப்நெட்டை அனுமதிக்கும் ஹோஸ்ட்டில், அந்தக் கோரிக்கை இன்னும் LAN இல் உள்ள தீர்வானியை அடையலாம்।

மூன்றாம் படி: பிணைய வெளிப்பாட்டை முனை வெளிப்பாட்டிலிருந்து பிரிக்கவும்

இப்போது எந்த ஃபயர்வால் விதியும் எட்டாத பகுதி। அவசர சுவிட்ச் இயந்திரத்திலிருந்து வெளியேறும் பாதைகளைத் தடுக்கிறது; இயந்திரத்தில் உள்ள மென்பொருள் என்க்ரிப்ஷனுக்கு முன் தரவைப் படிப்பதை அது தடுக்காது, அந்த மென்பொருள் டன்னலை சட்டப்படி பயன்படுத்துவதையும் தடுக்காது। கீலாகர், தீங்கிழைக்கும் நீட்டிப்பு, திறந்து விடப்பட்ட திரை, பரந்த அனுமதிகளுடன் ஒத்திசைவு கிளையண்ட்: இவை அனைத்தும் சுவிட்ச் மகிழ்ச்சியுடன் அனுமதிக்கும் இணைப்பு வழியாகத் தகவலை நகர்த்துகின்றன।

முதலாளி வேண்டுமென்றே நிறுவிய கண்காணிப்பு மென்பொருளுக்கும் இதுவே பொருந்தும்। பாதைகளைத் தடுப்பது அதை நீக்காது, புதிய VPN சேவையகத்தை வாங்குவது தீர்வல்ல, ஏனெனில் வெளிப்பாடு டன்னலுக்கு முன்பே உள்ளது।

கிளவுட் கணக்கிற்கு பதிவேற்றும் கிளிப்போர்டு மேலாளர் இதைக் கூர்மையாகக் காட்டுகிறது। போக்குவரத்து என்க்ரிப்ட் செய்யப்பட்டுள்ளது, இலக்கு அனுமதிக்கப்பட்டுள்ளது, அவசர சுவிட்ச் எல்லா நேரமும் ஆரோக்கியமான நிலையைத் தெரிவிக்கிறது।

நான்காம் படி: உங்கள் சோதனை ஆதரிக்கும் கூற்றை எழுதுங்கள்

கண்டறிதல் சோதனைக்குப் பிறகு குறிப்பிட்ட உண்மைகளைக் கூறலாம்: எந்தச் செயலிகள் தோல்வியடைந்தன, எந்தப் பாதைகள் நின்றன, DNS மற்றும் IPv6 எப்படி நடந்தன, டன்னல் விழுந்தபோது தடுப்பு நிலைத்ததா। இயக்க முறைமை சுத்தமானது என்று சொல்ல முடியாது, தொலை முனையின் சேவை உங்கள் உள்நுழைவைத் தனிப்பட்டதாக வைத்திருக்கும் என்றும் சொல்ல முடியாது।

இரு சிக்கல்களையும் தனித்தனியாக வைத்து ஒவ்வொன்றிற்கும் அதன் சொந்தக் கட்டுப்பாட்டைக் கொடுங்கள்:

• அவசர சுவிட்ச்: வரையறுக்கப்பட்ட தோல்வித் தேவை, ஒவ்வொரு கிளையண்ட் மேம்பாட்டிற்குப் பிறகும் மீண்டும் செய்யப்படும் கண்டறிதல் சோதனையால் சரிபார்க்கப்படுகிறது।
• சாதன நம்பிக்கை: ஆதரிக்கப்பட்ட புதுப்பிப்புகள், நம்பகமான மூலத்திலிருந்து முனை பாதுகாப்பு, விளக்கப்படாத அனுமதிகள் மற்றும் அங்கீகாரக் கோரிக்கைகளின் மறுஆய்வு।
• சம்பவம்: ஊடுருவல் சந்தேகிக்கப்படும்போது தளம் அல்லது நிறுவனத்தின் செயல்முறையைப் பின்பற்றுங்கள்; புதிய சேவையகம் சுத்தம் செய்யும் படி அல்ல।
• வெளிப்படுத்தல்: உதவி கேட்கும்போது தனிப்பட்ட விசைகள் அல்லது முழு நோயறிதல் காப்பகங்களை ஒட்ட வேண்டாம், ஏனெனில் பதிவுகளும் திரைப்பிடிப்புகளும் இணைப்பின் அதே ரகசியங்களைக் கொண்டுள்ளன।

அடுத்த புதுப்பிப்பிற்குப் பிறகு வரிசையை மீண்டும் இயக்குங்கள், ஏனெனில் அவசர சுவிட்ச் பதிப்புகளுடன் நகரும் உள்ளமைவு। நீங்கள் நம்பியிருக்கும் நடத்தை இன்னும் நீங்கள் பெறும் நடத்தையே என்பதற்கு சோதனையே ஒரே சான்று।