OpenVPN client-connect தோல்வி: disconnect சுத்தம் உத்தரவாதமா?
நிராகரிக்கப்பட்ட கிளையண்ட் firewall விதியையோ எழுதப்பட்ட பதிவையோ திரும்பப் பெறாது. callback ஒப்பந்தத்தை உங்கள் hook தானே செய்ய வேண்டிய rollback உடன் ஒப்பிடுங்கள்.
client-connect ஸ்கிரிப்ட் பூஜ்ஜியமற்ற குறியீட்டுடன் வெளியேறும்போது, OpenVPN கிளையண்டை நிராகரிக்கிறது, மேலும் இயக்குநர்கள் பொதுவாக தொடர்புடைய client-disconnect ஸ்கிரிப்ட் எல்லாவற்றையும் சரிசெய்யும் என்று கருதுகிறார்கள். பெரும்பாலும் அது ஒருபோதும் இயங்குவதில்லை, ஏனெனில் disconnect செயலாக்கம் connect நிலை எதை முடிக்க முடிந்தது என்பதைப் பொறுத்தது. நிராகரிப்பையும் rollback-ஐயும் ஒரே வழிமுறையாகக் கருதுவதே தோல்வியடைந்த உள்நுழைவை கசிந்த firewall விதியாகவோ அனாதைப் பதிவாகவோ மாற்றுகிறது. இவை இரண்டு தனித்தனி கடமைகள், அவற்றில் ஒன்று மட்டுமே தானியங்கியானது. சர்வர் நிலையை விட்டுவிட்டது எனக் குற்றம் சாட்டும் முன் hook-இன் சொந்த வெளியேறும் பாதையைப் படியுங்கள்.
பூஜ்ஜியமற்ற வெளியேற்றம் கிளையண்டை நிராகரிக்கிறது; அது உங்கள் வேலையைத் திரும்பப் பெறாது
client-connect-இன் வெளியேற்ற நிலை ஒரு அனுமதி முடிவு. பூஜ்ஜியம் என்பது அனுமதி, வேறு எதுவும் என்பது நிகழ்வு முழுமையாக நிறுவப்படும் முன் அதை இடிப்பது. அந்த ஒப்பந்தத்தில் ஸ்கிரிப்ட் வெளி உலகிற்கு ஏற்கனவே என்ன செய்தது என்பதை ஆய்வு செய்வது எதுவும் இல்லை. ஸ்கிரிப்ட் iptables விதியைச் சேர்த்திருந்தால், வரி எழுதியிருந்தால் அல்லது கணக்கியை அதிகரித்திருந்தால், அந்த மாற்றங்கள் நிராகரிப்பைத் தாண்டி நீடிக்கும்.
அதே சமச்சீரற்ற தன்மை செருகிகளுக்கும் பொருந்தும், அங்கு ஒரு நிகழ்வுக்கு பல connect செயல்பாடுகள் இயங்கலாம். பிந்தைய தோல்வி முந்தைய வெற்றியைப் பின்னோக்கி ரத்து செய்யாது, முந்தைய செயல்பாட்டிற்கு சகோதர செயல்பாடு தோல்வியடைந்தது எனத் தெரிந்துகொள்ள வழியில்லை.
நிராகரிப்பு தானியங்கி, சுத்தம் அல்ல
OpenVPN 2.6 கையேடு client-disconnect செயலாக்கத்தை முந்தைய connect செயலாக்கத்தின் வெற்றியுடன் இணைக்கிறது. ஆவணப்படுத்தப்பட்ட விதிவிலக்கு அடுக்குச் சங்கிலிகளை உள்ளடக்குகிறது: ஒரு connect படி ஏற்கனவே வெற்றியைத் திருப்பியிருந்தால், பிந்தைய connect படி தோல்வியடைந்தாலும், நிகழ்வு இடிக்கப்படும்போது தொடர்புடைய disconnect படிகள் இருந்தபோதிலும் இயங்கும். அந்த விதிவிலக்கு குறுகியது மற்றும் எத்தனை callbackகள் உள்ளமைக்கப்பட்டுள்ளன என்பதைப் பொறுத்தது, எனவே ஒரு shell ஸ்கிரிப்டைச் சோதிப்பது சங்கிலி பற்றி உங்களுக்கு எதுவும் சொல்லாது.
வடிவமைப்பதற்கு முன் உண்மையான உள்ளமைவை வரைபடமாக்குங்கள்: எந்த ஸ்கிரிப்ட், எந்த செருகி, எந்த வரிசையில் இயங்குகின்றன. கீழேயுள்ள அட்டவணை பாதி முடிந்த அமைப்பு என்ன விட்டுச் செல்கிறது என்பதைப் பட்டியலிடுகிறது.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
ஒவ்வொரு வரியும் கிளையண்டிற்கு ஒரே மாதிரியாகவும் ஹோஸ்டுக்கு வேறு மாதிரியாகவும் முடிகிறது. அவற்றில் எது நடந்தது எனக் கிளையண்ட் சொல்ல முடியாது, எனவே hook தோல்வி நிலையைத் திருப்பித் தரும் முன் தான் செய்ததைத் திரும்பப் பெற வேண்டும்.
தோல்வியடைந்த ஸ்கிரிப்டின் உள்ளேயே ஈடு செய்யுங்கள்
பங்கிடப்பட்ட நிலையைத் தொடும் முன் முடிந்த அனைத்தையும் சரிபார்க்கவும்: சான்றிதழ் புலங்கள், முகவரியின் கிடைக்கும் தன்மை, கிளையண்ட் சேர்ந்த குழு. மிக மலிவான நிராகரிப்பு எந்த ஒதுக்கீட்டிற்கும் முன் நடப்பதே. அமைப்பு பல வெளிப்புற செயல்பாடுகளை உள்ளடக்கியதும், எவை முடிந்தன என்பதைப் பதிவு செய்து, தோல்வி நிலையைத் திருப்பித் தரும் முன் அவற்றை எதிர் வரிசையில் திரும்பப் பெறுங்கள்.
ஒரு குறிப்பிட்ட நிகழ்வு: ஸ்கிரிப்ட் ஒவ்வொரு கிளையண்டிற்கும் firewall உள்ளீட்டை உருவாக்குகிறது, பின்னர் அதை விவரிக்கும் நிலை-வரியை எழுதத் தோல்வியடைகிறது. தோல்வியடைந்த கிளை இப்போது உருவாக்கிய உள்ளீட்டை அகற்றி பின்னர் பூஜ்ஜியமற்ற குறியீட்டுடன் வெளியேற வேண்டும். ஒருபோதும் திட்டமிடப்படாத disconnect நிகழ்வுக்காகக் காத்திருப்பதே ஒரு விதி அது நோக்கிய அமர்வை விட நீண்ட காலம் வாழும் வழி.
ஈடுசெய்தலை idempotent மற்றும் உரிமையுடையதாக்குங்கள்
சுத்தம் இரண்டு முறை இயக்கப் பாதுகாப்பாகவும், எதை நீக்கலாம் என்பதில் துல்லியமாகவும் இருக்க வேண்டும். முந்தைய முயற்சியின் தாமத நிகழ்வு, இரண்டும் பொதுவான பெயரையோ மறுசுழற்சி செய்யப்பட்ட சுரங்கப்பாதை முகவரியையோ பங்கிடுவதால் மட்டும் புதிய அமர்வின் ஒதுக்கீட்டை அகற்றக்கூடாது. குறிப்பிட்ட கைப்பிடியையோ செயல்பாட்டு ஐடியையோ ஆதாரத்துடன் பதிவு செய்து, பெயரால் அல்ல, அந்த விசையால் நீக்குங்கள். தரவுத்தள பரிவர்த்தனைகள் தரவுத்தளத்தின் சொந்த மாற்றங்களுக்கு மட்டுமே உதவும்; அந்த எல்லைக்கு வெளியேயுள்ள firewall விதிக்கு வெளிப்படையான ஈடுசெய் படி தேவை.
மாற்றத்திற்கும் சுத்தத்திற்கும் இடையில் செயல்முறை இறக்கலாம் எனக் கருதி, அட்டவணைப்படி வெளிப்புற நிலையை ஏற்கப்பட்ட கிளையண்ட் பட்டியலுடன் ஒப்பிடும் சமரசக்காரரைச் சேர்க்கவும்.
உண்மையில் வேறுபடும் மூன்று பாதைகளைச் சோதியுங்கள்
மூன்று நிகழ்வுகளைப் பயிற்சி செய்யுங்கள்: எதுவும் ஒதுக்கப்படும் முன் நிராகரிப்பு, பகுதி ஒதுக்கீட்டிற்குப் பின் நிராகரிப்பு, மற்றும் பின்னர் முடியும் சாதாரண ஏற்கப்பட்ட அமர்வு. அந்த மூன்றும் வெவ்வேறு பதிவு வரிகளையும் வெவ்வேறு எச்சங்களையும் உருவாக்குகின்றன. ஒவ்வொன்றிற்குப் பின் வெளிப்புற நிலையைச் சரிபார்க்கவும், கிளையண்டின் தோல்விச் செய்தியை மட்டுமல்ல, ஏனெனில் மூன்றில் இரண்டில் கிளையண்டின் தோல்வியே எதிர்பார்க்கப்பட்ட முடிவு.
hook-இன் நிலை, வெளியேற்ற நிலை மற்றும் எது ஒதுக்கப்பட்டது அல்லது விடுவிக்கப்பட்டது என்பதை அடையாளச் சான்றுகளை நீக்கிப் பதிவு செய்யுங்கள். தான் உருவாக்கிய ஆதாரத்தைப் பெயரிடும் hook பதிவே கசிந்த விதியை ஆறு மாதங்களுக்குப் பின் கண்டறியக்கூடியதாக்குகிறது.