Wi-Fi இலிருந்து செல்லுலாருக்கு மாறிய பிறகு kill-switch: எது உடைகிறது

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

திரையில் அந்த மூன்று நிலைகளையும் எதுவும் பிரிக்கவில்லை, எனவே காட்டி எந்த நிறத்தைக் காட்டுகிறது என்று கேட்பதற்குப் பதிலாக விதிகள் எந்த அடையாளங்களில் பொருத்தப்பட்டிருந்தன என்று கேளுங்கள். Linux-இல் ஒரு விதி ஒரு இடைமுகத்தையோ அதிலிருந்து நிரப்பப்பட்ட ipset-ஐயோ பெயரிடலாம்; Android-இல் setUnderlyingNetworks வழியாக எந்த அடிப்படை நெட்வொர்க்குகளைப் பின்பற்ற வேண்டும் என்று VpnService-க்குச் சொல்லலாம். ஒவ்வொரு பிணைப்பும் மாற்றப்படவிருக்கும் இணைப்பைச் சுட்டுகிறது, ஒவ்வொன்றும் பிறகு மீண்டும் மதிப்பிடப்பட வேண்டும்.

மாற்றம் உண்மையில் எதை மீண்டும் எழுதுகிறது

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

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

துளை போடாமல் வெளிச் சுரங்கத்தை மீண்டும் கட்டமைத்தல்

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

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

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

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

புதிய இணைப்பு IPv6 கொண்டு வரும்போது விதிகள் கொண்டு வராதபோது

செல்லுலார் மற்றும் விருந்தினர் நெட்வொர்க்குகள் அலுவலகத்தின் கம்பி LAN ஒருபோதும் செய்யாதபோதும் உலகளாவிய IPv6 முன்னொட்டை வழங்குகின்றன. IPv4 விதிகளாக மட்டுமே எழுதப்பட்ட கொள்கை — கையால் உருவாக்கப்பட்ட பெரும்பாலான iptables மற்றும் nftables செய்முறைகளின் இயல்புநிலை வடிவம் — இதில் எதையும் மூடவில்லை. சுரங்கம் இணைந்தே இருக்கும், IPv6 அணுகல் உள்ள பயன்பாடுகள் அதற்கு வெளியே செல்லும், சுரங்கம் உண்மையில் இயங்குவதால் காட்டி வேறுபாட்டைக் காட்ட முடியாது. எதிர்மறை நிலையும் அவ்வளவு பொதுவானது: IPv6-க்கு மட்டுமான விதிகளின் தொகுப்பு v6 வழங்காத நெட்வொர்க்கில் எதுவும் செய்யாது.

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

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

இரண்டாவது கட்டளை இயல்புநிலை வழியை அச்சிட்டு மூன்றாவது பூஜ்ஜியத்தைத் திருப்பித் தந்தால், புதிய இணைப்பு எந்த விதியும் கவனிக்காமல் இயந்திரத்தை IPv6 வழியாக வெளியே அழைத்துச் செல்லலாம். மாற்றத்திற்குப் பிறகு மூன்றையும் மீண்டும் இயக்குங்கள், ஏனெனில் சுவாரஸ்யமான எண் இரு இயக்கங்களுக்கு இடையிலான வேறுபாடு. இரண்டாவது எதையும் அச்சிடாவிட்டால் எதிர்மறை நிலை பொருந்தும், அங்கு எந்த v6-கனமான கொள்கையும் வெறும் அலங்காரம்.

தீர்வி அமர்வின் நடுவில் கைகளை மாற்றுகிறது

நவீன அமைப்புகளில் தீர்விகள் இணைப்புகளுடன் இணைக்கப்பட்டுள்ளன, எனவே புதிய இணைப்பு புதிய தீர்வித் தொகுப்புடனும் ஒருவேளை வேறு split-DNS பார்வையுடனும் வருகிறது. systemd-resolved ஒவ்வொரு இணைப்பிற்கும் ஒரு scope வைத்து வழியின் அடிப்படையில் அவற்றுக்கிடையே தேர்ந்தெடுக்கிறது, macOS ஆனது மாறும் சேமிப்பகத்திலிருந்து scoped தீர்விகளைப் படித்து இடைமுக வரிசையை மதிக்கிறது. தன் சொந்தத் தீர்வியை நிறுவும் கிளையண்ட் இணைப்பின் தீர்வியுடன் போட்டியிடுகிறது, யாரும் கவனிக்காத முன்னுரிமை விதிகளே வெற்றியாளரைத் தீர்மானிக்கின்றன. அப்போது பெயர் தீர்வு உடையலாம், பாக்கெட் வடிகட்டுதல் அதற்காக எழுதப்பட்டதைச் சரியாகச் செய்துகொண்டிருக்கும்போது.

கட்டமைக்கப்பட்ட தீர்வியை அல்ல, செயலில் உள்ள தீர்வியைப் படியுங்கள். systemd புரவலனில் status துணைக் கட்டளை ஒவ்வொரு scope-ம் எந்த இணைப்பிலிருந்து வந்தது, private-DNS பெயர் நடைமுறையில் உள்ளதா என்பதைக் காட்டுகிறது:

resolvectl status --no-pager
resolvectl query intranet.example.com

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

மாற்றத்தைப் பயிற்சி செய்து பதிவை வைத்திருங்கள்

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

விதிவிலக்குகளுக்குத் தனிப் பயணம் தேவை, பழைய நெட்வொர்க்கில் நியாயப்படுத்தப்பட்ட தவிர்ப்பு புதியதில் தானாக நியாயப்படுத்தப்படாது. வீட்டு LAN-இல் உள்ள அச்சுப்பொறி, NAS அல்லது captive portal ஆகியவற்றுக்கு செல்லுலாரில் இணையில்லை, அவற்றை அடைந்த விதிவிலக்கு இணையற்ற விதியாக மாறுகிறது.

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