ஃபெயில்ஓவர் சோதனை: நிறுவப்பட்ட TCP ஸ்ட்ரீம் தப்பிப்பிழைக்குமா?

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

ஒரே வெற்றி போலத் தோன்றும் இரண்டு முடிவுகள்

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

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

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

வெளியேற்றம் மாறும்போது சேவையகம் என்ன பார்க்கிறது

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

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

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

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

ஒரே பொது முகவரி ஏன் போதாது

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

RFC 3022 முகவரி மொழிபெயர்ப்பை விவரிக்கிறது, மொழிபெயர்க்கும் சாதனங்களுக்கிடையேயான நிலைப் பரிமாற்றத்தை காப்பு வடிவமைப்பின் பகுதியாகக் கருதுகிறது. மிதக்கும் முகவரி அல்லது நகலெடுக்கப்பட்ட சுயவிவரம் கட்டமைப்பை நகர்த்துகிறது, நிலையை நகர்த்துவதில்லை.

அதனால்தான் காப்பு வழியாக மட்டும் ping செய்யும் சோதனை மிகக் குறைவாகவே நிரூபிக்கிறது. ping க்கு இழக்க இணைப்பு நிலை இல்லை.

தேவை எவ்வளவு வலுவானது என்று முடிவு செய்யுங்கள்

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

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

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

பழைய ஸ்ட்ரீம் மற்றும் புதிய கோரிக்கையைச் சரிபாருங்கள்

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

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

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

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