ஒரே Linux ஹோஸ்டில் இரண்டு OpenVPN சுரங்கங்கள்: வழி யாருடையது?

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

இரண்டாவது இணைப்பு செய்ய வேண்டிய வேலையிலிருந்து தொடங்குங்கள்

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

ஒன்றின் மேல் ஒன்று வரும் குளங்கள் ரூட்டிங்கிற்கு முன்பே உடைகின்றன

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

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

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

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

ஒவ்வொரு சுயவிவரத்திற்கும் அதன் அலகை, ஒவ்வொரு முன்னொட்டிற்கும் உரிமையாளரைக் கொடுங்கள்

ஒவ்வொரு சுயவிவரமும் அதன் சொந்த நிகழ்வுப் பெயரையும் அதன் சொந்த கட்டமைப்புக் கோப்பையும் பெறுகிறது, எனவே office எனப்படும் நிகழ்வு office.conf ஐ ஏற்றுகிறது, lab எனப்படும் நிகழ்வு lab.conf ஐ ஏற்றுகிறது. அடைவுப் பட்டியலை நம்புவதற்குப் பதிலாக சேவை மேலாளர் மூலம் அந்த மேப்பிங்கை உறுதிப்படுத்துங்கள், ஏனெனில் drop-in எந்தக் கோப்பு ஏற்றப்படுகிறது என்பதை மாற்றலாம். மேப்பிங் தவறினால் நீங்கள் இயங்காத சுயவிவரத்தைச் சரிசெய்கிறீர்கள்.

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

மார்க்குகள் பதில்களை அவை வந்த இடைமுகத்திலேயே வைத்திருக்கும்

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

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

ஒரு இணைப்பை நிறுத்தி தனிமையை நிரூபிக்கவும்

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

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

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