பெரிய பதிவிறக்கங்களும் VPN-உம்: கோரிக்கையிலேயே பாதையைத் தேர்ந்தெடுக்கவும்

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

ரவுட்டரால் ஒரு பதிலை அளக்க முடியாதது ஏன்

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

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

சரிபார்ப்பு 1: பாதையைத் தேர்ந்தெடுக்கக்கூடிய முடிவுப் புள்ளி உள்ளதா?

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

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

சரிபார்ப்பு 2: மெட்டாடேட்டா உண்மையில் என்ன சொல்கிறது?

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

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

சரிபார்ப்பு 3: ஓட்டம் ஏற்கனவே உள்ளதா?

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

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

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

சரிபார்ப்பு 4: உண்மையான தேவை தாமதமா, வெளியேற்றம் அல்லவா?

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

tc qdisc replace dev eth0 root cake bandwidth 100mbit

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

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

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