இரண்டு VPN, ஒரு ரிசால்வர்: கடைசியாக எழுதியவரே வெல்கிறார்

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

கட்டுக்கதை: புதிய VPN தான் DNS-ஐ வைத்திருக்கிறது

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

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

பெயர் இடங்களை ரிசால்வர்களுடன் இணையுங்கள்

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

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

Windows-இல், பெயர் தீர்வுக் கொள்கை அட்டவணை சஃபிக்ஸ்களை குறிப்பிட்ட சேவையகங்களுக்குத் திருப்பலாம், ஒரு VPN கிளையண்ட் அங்கே விதிகளை நிறுவலாம். அடாப்டர் பட்டியலுக்குப் பதிலாகக் கொள்கையைச் சரிபார்க்கவும், ஏனெனில் பெயரைத் தீர்ப்பது அடாப்டர் பட்டியல் அல்ல.

ஒரு பூட்ஸ்ட்ராப் பாதையை வைத்திருங்கள்

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

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

ஒன்றின்மேல் ஒன்று விழும் முகவரிகள் DNS பிரச்சினை அல்ல

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

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

உண்மையான பயன்பாடுகளுடன் அதை நிரூபியுங்கள்

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

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