உங்கள் VPN நுழைவாயிலுக்கு இன்னும் புதுப்பிப்புகளை நிறுவ ஒரு வழி தேவை
பூட்டப்பட்ட நுழைவாயில் தனது களஞ்சியங்களை எட்டியாக வேண்டும். எந்தக் கட்டம் தோல்வியடைந்தது என்பதைக் கண்டறிந்து, பின்னர் வெளிச்செல் போக்குவரத்தைத் திறப்பதற்குப் பதிலாக அதே பாதையை அனுமதியுங்கள்.
சுரங்கப்பாதை அதன் பின்னால் உள்ள அனைவருக்கும் வேலை செய்கிறது, நுழைவாயில் அவர்களின் போக்குவரத்தை அனுப்புகிறது, இருப்பினும் இயந்திரமே ஒரு பாதுகாப்பு புதுப்பிப்பை நிறுவ முடியாது. சிக்கலின் வழக்கமான வடிவம் இதுதான்: அனுப்புதல் அனுமதி வாடிக்கையாளர்களுக்கு வழங்கப்பட்டது, நுழைவாயிலின் சொந்த வெளிச்செல் இணைப்புகள் திட்டத்தில் ஒருபோதும் சேர்க்கப்படவில்லை. தொகுப்பு மேலாளர் தனது சொந்த சாக்கெட்டுகளைத் திறக்கிறது, நுழைவாயிலிலிருந்து, தீவிரச் சுவர் கொள்கையில் நீங்கள் எங்கும் பெயரிடாத ஒரு களஞ்சியத்தை நோக்கி.
நுழைவாயிலைப் பூட்டுவது சரி. அது இணைப்புத் திருத்தங்களைப் பெறுவதை நிறுத்தும் அளவுக்கு இறுக்கமாகப் பூட்டுவது வேறு முடிவு, பொதுவாக தற்செயலானது.
உள்ளூர் வெளியீடு வாடிக்கையாளர் அனுப்புதல் அல்ல
அனுப்புதல் விதிகள் வேறொரு இடத்திலிருந்து வந்து நுழைவாயில் வழியாக வெளியேறும் பொதிகளுக்குப் பொருந்தும். நுழைவாயிலின் சொந்த புதுப்பிப்புப் போக்குவரத்து அவற்றுடன் ஒருபோதும் பொருந்தாது; அது உள்ளூரில் உருவாகி வெளியீட்டுப் பாதையில் செல்கிறது. இந்த வேறுபாடுதான் வாடிக்கையாளர் அணுகல் சரியாக வேலை செய்யும்போது சாத்தியமற்றதாகத் தோன்றும் தோல்வியை விளக்குகிறது.
இது சோதனைகளைத் தாண்டி நிற்கும் ஒரு கொள்கை இடைவெளியையும் விளக்குகிறது, ஏனெனில் சுரங்கப்பாதைக்குப் பின்னால் உள்ள மடிக்கணினியிலிருந்து ஒரு விரைவான சரிபார்ப்பு அனுப்புதல் சங்கிலி வேலை செய்கிறது என்பதை நிரூபிக்கிறது, புரவலனின் சொந்த இணைப்புகளைப் பற்றி எதுவும் சொல்லவில்லை. நுழைவாயிலை இரண்டு பொருள்களாகக் கருதுங்கள்: அனுப்புதல் சங்கிலி கொண்ட திசைவி மற்றும் வெளியீட்டுச் சங்கிலி கொண்ட புரவலன். இரண்டுக்கும் ஒரு கருத்து தேவை, பொதுவாக ஒன்று மட்டுமே எழுதப்படுகிறது.
தோல்வியடைந்த கட்டத்தைப் பெயரிடுங்கள்
புதுப்பிப்புப் பிழைகள் வெவ்வேறு எல்லைகளைப் பெயரிடுகின்றன, எது தோல்வியடைந்தது என்பதைப் படிக்கும் முன் துறைமுக விதிக்குப் பாய்வது ஒரு பிற்பகலை வீணாக்குகிறது. தீர்க்க முடியாத களஞ்சியப் பெயர் resolver கேள்வி, போக்குவரத்துக் கேள்வி அல்ல.
getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update
வெற்றிகரமான தேடலுக்குப் பின் வரும் நேர முடிவு கேள்வியைப் போக்குவரத்துக்கு நகர்த்துகிறது: தொகுப்பு மேலாளர் உண்மையில் எந்த முகவரி, எந்தத் துறைமுகம் மற்றும் எந்தக் கட்டமைக்கப்பட்ட ப்ராக்ஸியை முயற்சித்தது. TLS சரிபார்ப்புத் தோல்வி மூன்றாவது, முற்றிலும் வேறு விஷயம், அது இணைப்பு பேச்சுவார்த்தைக்கு போதுமான அளவு வேலை செய்தது என்பதைக் குறிக்கிறது. காப்பக அங்கீகாரம் பற்றிய புகார் நான்காவது கட்டம், அது அணுகல்தன்மையை விட கையொப்பமிடப்பட்ட மெட்டாடேட்டாவைப் பற்றியது. நான்கு கட்டங்கள், நான்கு வெவ்வேறு பழுதுபார்ப்புகள், ping எப்போதும் எந்தத் தொகுப்பு மேலாளரும் பயன்படுத்தாத ஒரு நெறிமுறையை மட்டுமே விவரிக்கிறது.
விதியைச் சேர்ப்பதற்கு முன் மூலப் பட்டியலைப் படியுங்கள்
நினைவில் உள்ள மூலங்களுக்குப் பதிலாக உண்மையான மூல URIகள் மற்றும் பயனுள்ள ப்ராக்ஸி கட்டமைப்பைப் பட்டியலிடுங்கள். சாதாரண HTTPக்காக எழுதப்பட்ட விதி மூலம் HTTPS ஆக இருக்கும்போது பயனற்றது, ஷெல் அறிந்த ப்ராக்ஸி பூட்டின் போது வேறு சூழலுடன் தொடங்கும் சேவைக்கு கண்ணுக்குத் தெரியாததாக இருக்கலாம்.
APT இல் HTTP போக்குவரத்து ஆவணம் சூழல் மற்றும் APT சார்ந்த ப்ராக்ஸி அமைப்புகளை உள்ளடக்குகிறது, ஒவ்வொரு புரவலனுக்குமான தேர்வுகள் உட்பட, அதன் HTTPS போக்குவரத்துக்கு அதன் சொந்த சரிபார்ப்பு அமைப்புகள் உள்ளன. உலாவியின் பாதையும் தொகுப்பு மேலாளரின் பாதையும் தனித்தனிப் பாதைகள், ஒரே இயந்திரத்திலும் கூட.
மூலங்கள் எந்த முகவரிக் குடும்பங்களுக்குத் தீர்க்கப்படுகின்றன என்பதைக் கவனியுங்கள். IPv4ஐ மட்டும் அனுமதிக்கும் விதி, மூலங்கள் AAAA பதிவை விரும்பும் புரவலனில் தோல்வியடைந்து கொண்டே இருக்கும், பிழை இடைவிடாமல் தோன்றுவது போல் தெரிகிறது, ஏனெனில் எந்தப் பதில் முதலில் வருகிறது என்பதைப் பொறுத்தது.
ஒரு பராமரிப்புப் பாதையைத் தேர்ந்தெடுத்து அதில் நிலைத்திருங்கள்
மூன்று பாதுகாக்கக்கூடிய விருப்பங்கள் உள்ளன: பராமரிப்புப் போக்குவரத்து சுரங்கப்பாதை வழியாக, நிர்வகிக்கப்பட்ட புதுப்பிப்பு ப்ராக்ஸி வழியாக, அல்லது குறுகிய நேரடி விதிவிலக்கு வழியாக. ஒன்றை வேண்டுமென்றே தேர்ந்தெடுத்து resolver அதற்கு உடன்படச் செய்யுங்கள், ஏனெனில் பெயர்கள் ஒரு திசையில் தீர்க்கப்பட்டு இணைப்புகள் மற்றொரு திசையில் செல்லும் பிளவு யாராலும் விளக்க முடியாத தோல்விகளை உருவாக்குகிறது.
நீங்கள் எதைத் தேர்ந்தெடுத்தாலும், அது வரம்பற்ற மாற்றுப் பாதையாக மாறக்கூடாது. சுரங்கப்பாதை கீழே இருக்கும்போது நேரடி வெளிச்செல் போக்குவரத்து தடை செய்யப்பட்டிருந்தால், அமைதியாக எல்லாவற்றையும் அனுமதிக்கும் பராமரிப்பு விதிவிலக்கு பழுதுபார்ப்பு வேடத்தில் கொள்கை மாற்றமாகும். சுரங்கப்பாதையின் சொந்த முனைப்புள்ளி மற்றும் bootstrap தேவைகளைக் களஞ்சிய அணுகலிலிருந்து தனி வகையில் வைத்திருங்கள், ஏனெனில் அவை வெவ்வேறு இலக்குகளை நோக்கி வெவ்வேறு வழிகளில் தோல்வியடைகின்றன, எனவே ஒரு விலக்கு மற்றொன்றை மூட முடியாது.
சரிபார்ப்புகளைப் பலவீனப்படுத்தாமல் சரிபார்க்கவும்
ஏற்கனவே கொள்கையைக் கொண்ட தீவிரச் சுவர் வழியாகவே எல்லையைப் பயன்படுத்துங்கள், ஒரு வழிகாட்டி அதைப் பயன்படுத்தியதால் இரண்டாவது மேலாளரைச் சேர்ப்பதற்குப் பதிலாக. பின்னர் பராமரிக்கப்படும் கொள்கையின் கீழ் மெட்டாடேட்டா புதுப்பித்தல் மற்றும் ஒரு உண்மையான தொகுப்பு பரிவர்த்தனையை இயக்கி, வெளியேறும் நிலையை மட்டுமல்ல வெளியீட்டையும் படியுங்கள்.
வெற்றிகரமான போக்குவரத்து சரிபார்ப்பைத் தளர்த்த அனுமதி அல்ல. காப்பக அங்கீகாரமும் TLS சேவையக அடையாளமும் தனித்தனி உத்தரவாதங்கள், பிழையை அமைதிப்படுத்த அவற்றில் ஒன்றை முடக்குவது நீங்கள் எதை நம்புகிறீர்கள் என்பதை மாற்றுகிறது, எதை அடைய முடியும் என்பதை அல்ல.
சுரங்கப்பாதை இல்லாத நிலையை வேண்டுமென்றே சோதித்து முடிக்கவும். சுரங்கப்பாதை இல்லாமல் நுழைவாயில் எப்படி நடந்துகொள்கிறது என்பதை அறிவது வடிவமைப்பின் பகுதி, ஒரு இடையூறின் போது அதைக் கண்டுபிடிப்பது அல்ல. சுரங்கப்பாதையைக் கீழே இறக்குங்கள், மெட்டாடேட்டா புதுப்பித்தலை இயக்கி, புரவலன் நீங்கள் நினைத்த விதத்திலேயே தோல்வியடைகிறது என்பதை உறுதிப்படுத்துங்கள், அமைதியாகத் திறந்த பாதைக்குத் திரும்பாமல். களஞ்சியம் மற்றும் ப்ராக்ஸியின் சான்றுகளைப் பகிரப்பட்ட கண்டறிதலுக்கு வெளியே வைத்து, புதுப்பிப்புப் பாதையின் உரிமையாளர் யார் என்பதைக் குறிக்கும் குறிப்பை விட்டுச் செல்லுங்கள்.