OpenVPN சேவையகம் nopool உடன்: வெளிப்படையான குளப் வரம்பை அறிவிக்கவும்

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

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

உங்களிடம் ஏற்கனவே உள்ள துணை வலையத்திலிருந்து தொடங்குங்கள்

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

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

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

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

nopool சேர்த்து வரம்பை அறிவிக்கவும்

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

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

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

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

நிலையான ஒதுக்கீடுகளை மாறும் வரம்பிற்கு வெளியே வையுங்கள்

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

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

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

வாழ்க்கைச் சுழற்சி வழியாகப் பயன்படுத்தி, பின்னர் சரிபார்க்கவும்

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

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

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

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

வரம்பு மாற்றத்தைப் பின்னிழுக்கும்

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

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

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