உங்கள் ஸ்பிளிட்-டனல் விதி ஒரு சேவையுடன் பொருந்துவதை ஏன் நிறுத்தியது

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

விதி எதைப் பின்னுகிறது, DNS எதைத் திருப்பித் தருகிறது

ஸ்பிளிட்-டனல் விதி இலக்குகளைப் பற்றிய ஒரு நிலையான கூற்று, பொதுவாக முன்னொட்டு, வழி அல்லது முகவரிப் பட்டியலாக வெளிப்படுத்தப்படுகிறது. அனுப்பும் நேரத்தில் பொதியின் இலக்கிற்கு எதிராக அது மதிப்பிடப்படுகிறது. ஹோஸ்ட்பெயர் என்பது ஆயுளும் தேக்ககமும் கொண்ட முகவரிகளின் தொகுப்பைத் திருப்பித் தரும் தேடல், மேலும் பதில் resolver, வினா வகை மற்றும் நிமிடத்தைப் பொறுத்து வேறுபடலாம்.

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

பொருத்தம் உடையும் மூன்று வழிகள்

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

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

செயலி உண்மையில் பயன்படுத்தும் இலக்கைப் படியுங்கள்

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

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

அறிகுறியை அல்ல, இயங்குமுறையைச் சரிசெய்யுங்கள்

தயாரிப்பு பராமரிக்கப்படும் கள அடிப்படையிலான வழிகாட்டலை ஆதரித்தால், அதைப் பயன்படுத்தி அதன் ஆவணப்படுத்தப்பட்ட புதுப்பித்தல் மற்றும் எல்லை நடத்தையைப் பின்பற்றுங்கள். அது நிலையான ஊகத்தை பராமரிக்கப்படும் பதிலால் மாற்றுகிறது, அம்சம் ஆவணப்படுத்தப்பட்டபடி செயல்படுவதைச் சார்ந்திருப்பதன் விலையில்.

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

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

நோக்கத்தின் இரு பகுதிகளையும் சரிபார்க்கவும்

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

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

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