OpenVPN client-connect వైఫల్యం: disconnect సమయంలో శుభ్రత హామీ ఉందా?
తిరస్కరించబడిన క్లయింట్ firewall నియమాన్ని లేదా రాసిన రికార్డును తిరిగి తీసుకోదు. callback ఒప్పందాన్ని మీ hook తానే చేయాల్సిన రోల్బ్యాక్తో పోల్చండి.
client-connect స్క్రిప్ట్ సున్నా కాని కోడ్తో నిష్క్రమించినప్పుడు, OpenVPN క్లయింట్ను తిరస్కరిస్తుంది, మరియు నిర్వాహకులు సాధారణంగా సంబంధిత client-disconnect స్క్రిప్ట్ అన్నీ సరిచేస్తుందని భావిస్తారు. చాలాసార్లు అది ఎప్పటికీ నడవదు, ఎందుకంటే disconnect ప్రాసెసింగ్ connect దశ ఏమి పూర్తి చేయగలిగిందనే దానిపై ఆధారపడి ఉంటుంది. తిరస్కరణను మరియు రోల్బ్యాక్ను ఒకే యంత్రాంగంగా పరిగణించడమే విఫలమైన లాగిన్ను లీక్ అయిన 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 సంఘటన కోసం ఎదురుచూడటమే ఒక నియమం తాను లక్ష్యంగా పెట్టుకున్న సెషన్ కంటే ఎక్కువ కాలం జీవించే విధానం.
పరిహారాన్ని ఐడెంపోటెంట్ మరియు యాజమాన్యంగా మార్చండి
శుభ్రత రెండుసార్లు నడపడానికి సురక్షితంగా ఉండాలి మరియు ఏమి తొలగించవచ్చో ఖచ్చితంగా ఉండాలి. మునుపటి ప్రయత్నం నుండి ఆలస్యంగా వచ్చిన సంఘటన, రెండూ సాధారణ పేరు లేదా పునర్వినియోగించిన టన్నెల్ చిరునామాను పంచుకుంటున్నందుకు మాత్రమే కొత్త సెషన్ కేటాయింపును తొలగించకూడదు. నిర్దిష్ట హ్యాండిల్ లేదా ఆపరేషన్ ఐడీని వనరుతో పాటు నమోదు చేయండి, మరియు పేరుతో కాదు, ఆ కీతో తొలగించండి. డేటాబేస్ లావాదేవీలు డేటాబేస్ స్వంత మార్పులకు మాత్రమే సహాయపడతాయి; ఆ పరిమితికి బయట ఉన్న firewall నియమానికి స్పష్టమైన పరిహార దశ అవసరం.
ప్రక్రియ మార్పు మరియు శుభ్రత మధ్య చనిపోవచ్చని ఊహించండి, మరియు షెడ్యూల్ ప్రకారం బాహ్య స్థితిని ఆమోదించిన క్లయింట్ జాబితాతో పోల్చే సమన్వయకర్తను జోడించండి.
నిజంగా భిన్నమైన మూడు మార్గాలను పరీక్షించండి
మూడు సందర్భాలను సాధన చేయండి: ఏదీ కేటాయించకముందే తిరస్కరణ, పాక్షిక కేటాయింపు తర్వాత తిరస్కరణ, మరియు తర్వాత ముగిసే సాధారణ ఆమోదించిన సెషన్. ఆ మూడూ వేర్వేరు లాగ్ పంక్తులు మరియు వేర్వేరు అవశేషాలను ఉత్పత్తి చేస్తాయి. ప్రతిదాని తర్వాత బాహ్య స్థితిని ధృవీకరించండి, క్లయింట్ వైఫల్య సందేశాన్ని మాత్రమే కాదు, ఎందుకంటే మూడింటిలో రెండింటిలో క్లయింట్ వైఫల్యమే ఆశించిన ఫలితం.
hook దశ, నిష్క్రమణ స్థితి మరియు ఏమి కేటాయించబడిందో లేదా విడుదల చేయబడిందో, ఆధారాలు మినహాయించి లాగ్ చేయండి. తాను సృష్టించిన వనరును పేర్కొనే hook లాగే లీక్ అయిన నియమాన్ని ఆరు నెలల తర్వాత కనుగొనగలిగేలా చేస్తుంది.