சேவையகமா வாடிக்கையாளரா: இரட்டைப் பங்குள்ள Pi-இல் எந்த OpenVPN அலகு

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

அலகின் பெயரை அது ஏற்றும் கோப்பகத்துடன் பொருத்துங்கள்

Upstream 2.6 இரண்டு வார்ப்புரு அலகுகளை வழங்குகிறது, [email protected] மற்றும் [email protected]. சேவையக வார்ப்புரு /etc/openvpn/server இல் தொடங்கி அங்கிருந்து %i.conf ஐ ஏற்றுகிறது. வாடிக்கையாளர் வார்ப்புரு /etc/openvpn/client இல் தொடங்குகிறது. roaming எனப்படும் நிகழ்வு ஒரே நேரத்தில் இரு இடங்களிலும் இருக்க முடியும், சேவையகமாகவும் வாடிக்கையாளராகவும், தொடர்பற்ற இரண்டு கட்டமைப்புகளுடன், சரத்தைத் தவிர அவற்றுக்கிடையே எந்த இணைப்பும் இல்லாமல்.

கோப்பு முறைமைக்குப் பதிலாக systemd-ஐக் கேளுங்கள், ஏனெனில் தொகுப்பு உருவாக்குபவர்கள் வேலைக் கோப்பகத்தையோ இரும நிரல் பெறும் வாதங்களையோ மாற்றக்கூடிய கூடுதல் கோப்புகளைச் சேர்க்கிறார்கள்.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

பாக்கெட்டின் திசையால் தீர்மானியுங்கள், இடைமுகத்தின் பெயரால் அல்ல

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

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

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

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

ஒரு நிகழ்வின் இயல்புநிலைப் பாதை மற்றொன்றின் பதில்களைப் பிடிக்கலாம்

மேல்நிலை வாடிக்கையாளர் தள்ளும் redirect-gateway இயந்திரத்தில் உள்ள மற்ற அனைத்துடனும் போட்டியிடும் இயல்புநிலைப் பாதையை நிறுவுகிறது, சேவையகம் அலைந்து திரியும் பயனர்களுக்கு அனுப்பும் பதில்கள் உட்பட. OpenVPN சுரங்கம் அடையக்கூடியதாக இருக்கத் தனது சொந்த இணை முகவரிக்கு விதிவிலக்கு அளிக்கிறது, ஆனால் அந்த விதிவிலக்கு விடுதி வலையமைப்பில் அமர்ந்திருக்கும் தொலைபேசி பற்றி எதுவும் சொல்லவில்லை.

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

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

ip route get 203.0.113.44
ip rule show

ஒரு பங்கை மீண்டும் தொடங்கி மற்றொன்று தப்பிப்பிழைத்ததை நிரூபியுங்கள்

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

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

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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