Access Server இலிருந்து Community OpenVPN வரை: எதை மீண்டும் கட்ட வேண்டும்

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

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

இரு பிரிவுகளும் பரிமாற்றம் செய்ய முடியாத இடம்

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

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

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

அடையாளம் சான்றிதழ் கோப்புகளுடன் மாற்றப்படுவதில்லை

பழைய அதிகாரத்தின் சான்றிதழ்கள் புதிய சேவையில் சரியாகப் பகுக்கப்படலாம், இருந்தும் தவறான அடையாளமாக இருக்கலாம், ஏனெனில் பழைய தயாரிப்பு அவற்றை புதியது பார்க்க முடியாத கணக்கு நிலையுடன் இணைத்தது. முதலில் புதிய பிரிவு சான்றிதழால் மட்டும், PAM அல்லது RADIUS ஐ அடையும் செருகியால், அல்லது கலவையால் அங்கீகரிக்கிறதா என முடிவு செய்து, பின்னர் ஒவ்வொரு விருப்பமும் தேவையான பண்புகளைத் தக்கவைக்கிறதா எனச் சரிபார்க்கவும். ஒவ்வொரு பயனருக்கும் அடையாளம் இல்லாத பங்கிடப்பட்ட சான்றிதழ் அதை வைத்திருப்பவர் அனைவருக்கும் ஒரே அனுமதிச் சீட்டு. ரத்துசெய்தலும் முதல் நாளிலிருந்து வேலை செய்ய வேண்டும், அதாவது Community OpenVPN இல் crl-verify குறிப்பிடும் CRL கோப்பு மற்றும் அதை மீண்டும் உருவாக்கும் செயல்முறை.

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

வழித்தடம் மற்றும் பெயர் தீர்வு உள்ளமைப்பை எழுதுபவரைப் பின்பற்றுகின்றன

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

ஒவ்வொரு வாடிக்கையாளரின் நடத்தைக்கு client-config-dir மற்றும் வாடிக்கையாளர் சான்றிதழின் common name பெயரில் ஒரு கோப்பு தேவை, தளம்-முதல்-தளம் இணைக்கு அதன் பின்னால் உள்ள முன்னொட்டுகளுக்கு iroute உள்ளீடுகள் தேவை. பெயர் தவறாக இருந்தால் விருப்பங்கள் பிழையின்றி புறக்கணிக்கப்படும். உற்பத்தி அல்லாத ஒரு வாடிக்கையாளருடன் அதன் சொந்த முகவரிக் குளத்தில் சோதித்து, பின்னர் வழங்கப்பட்ட முகவரி, பெற்ற வழிகள் மற்றும் அது முடித்த தீர்வி அமைப்புகளைப் படியுங்கள்.

பழைய சேவை திரும்ப வரும்படி மாற்றத்தை வரிசைப்படுத்துங்கள்

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

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

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

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