OpenVPN வழி அறிவுறுத்தலில் wildcard ஏன் வேலை செய்ய முடியாது

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

வழி எதை நிறுவுகிறது, எதை ஒருபோதும் படிக்காது

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

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

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

இலக்கு உண்மையில் ஒரு முன்னொட்டாக இருக்கும்போது

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

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

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

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

வேலையின் அலகு ஒரு ஹோஸ்ட் பெயராக இருக்கும்போது

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

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

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

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

ப்ராக்ஸி விருப்பம் எதை உள்ளடக்கவில்லை

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

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

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

இரு பாதைகளையும் சோதித்தல், மகிழ்ச்சியானதை மட்டும் அல்ல

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

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