OPNsense பின்னால் OpenVPN கிளையன்ட்களின் நிலையான முகவரிகள்

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

OPNsense இந்த override களை சேவையகத்தின் கிளையன்ட்-குறிப்பிட்ட அமைப்புகளில் வைத்திருக்கிறது, சான்றிதழின் பொதுப் பெயரை விசையாகக் கொண்டு, இது பொதுப் பெயரை முகவரித் திட்டத்தின் பகுதியாக ஆக்குகிறது.

ஒட்டும் லீஸ் நிலையான முகவரி அல்ல

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

மாறும் மாற்று, அதாவது client-connect ஸ்கிரிப்ட் மற்றும் மாறும் புதுப்பிப்புகள் மூலம் VPN ஐ DNS உடன் இணைப்பது, வேலை செய்கிறது, புதுப்பிப்புகளை ஏற்கும் resolver உடன் ஒவ்வொரு இணைப்பிலும் ஒரு ஸ்கிரிப்ட் தேவை. சாதனத்தில் நீங்கள் விற்பனையாளர் வழங்கும் தொகுப்புகளுக்கே வரம்பிடப்பட்டுள்ளீர்கள், பொதுவாக அங்கேயே அந்தத் திட்டம் நிற்கிறது.

யாரும் ரசிக்காத /30 கணக்கு

இயல்புநிலை net30 இடவியலில் ஒவ்வொரு கிளையன்டும் தனக்கான /30 ஐப் பெறுகிறது: முதல் பயன்படுத்தக்கூடிய முகவரி சேவையகப் பக்கம் செல்கிறது, இரண்டாவது கிளையன்டுக்கு. எனவே override கள் சேவையகத்தின் மாறும் டனல் வலையமைப்பிற்கு வெளியே இருக்க வேண்டும், அதாவது முதலில் அந்த வலையமைப்பை விரிவாக்க வேண்டும். 10.8.0.0/24 இல் உள்ள சேவையகம் 10.8.0.0/23 க்கு நகரலாம், பழைய வரம்பின் பாதியை மாறும் கிளையன்ட்களுக்கும் மறுபாதியை override களுக்கும் விட்டுவிட்டு. அசல் /24 ஐக் கூடுதல் IPv4 உள்ளூர் வலையமைப்பாகச் சேர்க்கவும், இரு பாதிகளுக்குமான போக்குவரத்து டனலுக்குள் வழித்தடப்படும்.

ஒவ்வொரு override முகவரியும் /30 எல்லையில் விழ வேண்டும், எனவே கடைசி ஆக்டெட் நான்கின் மடங்கு. 10.8.1.0 இல் /30 கிளையன்டுக்கு 10.8.1.2 தருகிறது, DNS பதிவு சுமப்பது அந்த முகவரியே. அதற்குப் பதிலாக 10.8.1.3 தேர்ந்தெடுத்தால் இணைந்து ஆனால் போக்குவரத்தைக் கடத்த முடியாத கிளையன்ட் உருவாகிறது, ஏனெனில் அந்த முகவரி இடவியல் அவருக்கு ஒருபோதும் வழங்காத துணைவலையமைப்பைச் சேர்ந்தது.

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

உள்ளூர் வலையமைப்புகளும் கிளையன்ட்கள் வினவும் மண்டலமும்

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

தொலை கிளையன்ட்கள் உண்மையில் வினவும் மண்டலத்தில் பதிவுகளை வெளியிடுங்கள். LAN resolver மட்டுமே சேவை செய்யும் மண்டலத்தின் பதிவு, தள்ளப்பட்ட resolver வேறெங்கோ சுட்டும் கிளையன்டுக்குத் தெரியாது, தவறான மண்டலத்தில் மேலும் பதிவுகளைச் சேர்த்தால் அது ஒருபோதும் சரியாகாது. எதையும் சேர்ப்பதற்கு முன் தள்ளப்பட்ட DNS விருப்பத்தையும் தேடல் டொமைனையும் உறுதிப்படுத்துங்கள்.

புதிய இணைப்பில் என்ன சரிபார்க்க வேண்டும்

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

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