FreeBind vs After=: systemd சாக்கெட்டை VPN முகவரியுடன் இணைப்பது

துவக்கத்தில் நிலையான VPN முகவரியை இணைக்கும் சாக்கெட் அலகு, சுரங்கப்பாதை அதை ஒதுக்குவதற்கு முன்பே தோல்வியடையலாம், அதன் பின்னால் உள்ள சேவை ஒருபோதும் தொடங்காது. இரண்டு சுவிட்சுகள் தீர்வுகள் போலத் தெரிகின்றன, அந்தச் சிக்கலின் வெவ்வேறு பாதிகளைத் தீர்க்கின்றன. முகவரி இன்னும் இல்லாதபோதே FreeBind systemd-ஐ கேட்பவரை உருவாக்க அனுமதிக்கிறது. After= பணிகளை மட்டும் ஒழுங்குபடுத்துகிறது, எனவே எப்போது விஷயங்கள் தொடங்குகின்றன என்பதை மாற்றுகிறது, ஆனால் முகவரி முன்பே வரச் செய்யாது.

இரண்டு வெவ்வேறு சிக்கல்கள், இரண்டு வெவ்வேறு சுவிட்சுகள்

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

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

FreeBind: முகவரிக்கு முன்பே கேட்பவர்

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

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

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

systemd சாக்கெட் குறிப்பு இந்த விருப்பத்தின் பின்னால் உள்ள IPv4 மற்றும் IPv6 நடத்தையை ஆவணப்படுத்துகிறது, முக்கியமான விவரம் அது இணைப்புக்குப் பொருந்தும், வழிமாற்றத்திற்கு அல்ல. அதில் எதுவும் முகவரியை ஒதுக்கவில்லை அல்லது VPN-ஐத் தொடங்கவில்லை. FreeBind கேட்பவருக்கு வழங்கப்படும் அனுமதி, இடைமுகத்திற்கான மாற்று அல்ல.

After= மற்றும் Wants=: வரிசை தயார்நிலை அல்ல

வரிசையும் தேவையும் தனித்தனி அச்சுகள், அவற்றைக் கலப்பது சரியான வரிசையில் தொடங்கியும் தோல்வியடையும் அலகுகளை உருவாக்குகிறது. After=vpn-client.service என்பது இரண்டு பணிகளும் தொடங்கினால், இது மற்றது தொடங்கும் வரை காத்திருக்கும் என்பதை மட்டுமே குறிக்கிறது. இது VPN-ஐ இழுக்காது, VPN இணைப்பை முடிக்கும் வரை காத்திருக்காது.

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

systemctl cat மற்றும் systemctl show -p After -p Wants -p Requires மூலம் அலகு உண்மையில் என்ன அறிவிக்கிறது என்பதைச் சரிபார்க்கவும். மூன்று வெவ்வேறு அடைவுகளின் drop-in நீங்கள் ஒருபோதும் எழுதாத வழிமுறைகளைச் சேர்க்கலாம், systemd பயனுள்ள அலகை மட்டுமே படிக்கிறது.

network-online.target செய்யாதது

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

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

நீங்கள் உண்மையில் தேர்ந்தெடுத்த வாழ்க்கைச் சுழற்சியைச் சோதிக்கவும்

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

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

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

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