క్లయింట్ హుక్ లేదా సర్వర్ హుక్? OpenVPN స్క్రిప్ట్ ఎక్కడ నడుస్తుంది
సర్వర్ కాన్ఫిగ్లోని స్క్రిప్ట్ పాత్ సర్వర్పై ఉండే పాత్. పని చేయాల్సిన మెషీన్ ప్రకారం హుక్ను ఎంచుకోండి, మరియు push ల్యాప్టాప్లో కోడ్ను నడుపుతుందనే ఆశను వదిలేయండి.
పని స్పష్టంగా ఉంది: ల్యాప్టాప్ కనెక్ట్ అయినప్పుడు దానిపై ఏదో మారాలి. సవరించబడుతున్న కాన్ఫిగరేషన్ సర్వర్కు చెందుతుంది, మరియు అక్కడే ఊహ బద్దలవుతుంది. సర్వర్ ఫైల్లోని పాత్ ఆ సర్వర్పైన ఫైల్ను సూచిస్తుంది, మరియు ఎంత push చేసినా ఏ ప్రక్రియ దాన్ని నడుపుతుందనేది మారదు. రెండు హుక్ల మధ్య ఎంపిక అనేది ప్రధానంగా ఏ మెషీన్ పనిని కలిగి ఉందో నిర్ణయించుకోవడం మరియు దాని నుండి వచ్చే పరిమితులను అంగీకరించడం.
రెండు మెషీన్లు, మొదట సమాధానం ఇవ్వాల్సిన రెండు ప్రశ్నలు
స్థితి మార్పు ఎక్కడ జరగాలో అడగండి, ఆ తర్వాత ఏ సంఘటన దానికి సరిపోతుందో అడగండి. మార్పు ప్రతి వినియోగదారు అనుమతి లేదా ప్రతి క్లయింట్ కాన్ఫిగరేషన్ నిర్ణయం అయితే, వినియోగదారు డైరెక్టరీ తెలిసిన చోటికే చెందుతుంది: సర్వర్కు. మార్పు మార్గం అయితే, resolver సెట్టింగ్ లేదా ఎండ్పాయింట్పై స్థానిక సహాయకం అయితే, అది ఎండ్పాయింట్కే చెందుతుంది, మరియు ఎండ్పాయింట్ మాత్రమే దాన్ని చేయగలదు.
ఈ రెండు ప్రశ్నలకు వ్యతిరేక క్రమంలో సమాధానం ఇవ్వడమే వ్యక్తులు Windows ల్యాప్టాప్కు బ్యాచ్ ఫైల్ను push చేయడానికి ప్రయత్నించే స్థితికి చేరుకోవడం. సర్వర్కు ఎవరు కనెక్ట్ అయ్యారో తెలుసు; ల్యాప్టాప్కు దాని స్వంత నెట్వర్క్ స్టాక్ ఎలా ఉంటుందో తెలుసు. ఏ ఒక్కదానికీ మరొకదాని సమాచారం ఉండదు, మరియు ప్రయత్నం సాధారణంగా స్పష్టమైన లోపం బదులు నిశ్శబ్దంగా విఫలమవుతుంది.
రెండింటికీ ముందు మూడవ ప్రశ్న అడగడం విలువైనది: మీకు కావాల్సిన హుక్ను ప్లాట్ఫారమ్ అసలు అందిస్తుందా? తన కాన్ఫిగరేషన్ను తానే ఉత్పత్తి చేసే పరికరం అదే సంఘటన పేర్లను అందించకపోవచ్చు, మరియు .ovpn ఫైల్ను దిగుమతి చేసే డెస్క్టాప్ క్లయింట్ ఆ ఫైల్ కోసం వ్రాయబడిన క్లయింటే అయి ఉండాల్సిన అవసరం లేదు. ప్లాట్ఫారమ్ను మొదట నిర్ధారించుకోవడం అక్కడ లేని హుక్ చుట్టూ డిజైన్ చేయడాన్ని తప్పిస్తుంది. మీ ముందున్న మెషీన్కు ఏ డాక్యుమెంటేషన్ నిజంగా వర్తిస్తుందో కూడా అది చెబుతుంది.
సర్వర్ వైపు ఎంపిక: ప్రతి కనెక్షన్కు ఒక సంఘటన
client-connect స్క్రిప్ట్ ధృవీకరించబడిన క్లయింట్ కనెక్ట్ అయినప్పుడు సర్వర్ ప్రక్రియ సందర్భంలో నడుస్తుంది, మరియు common name మరియు కేటాయించిన చిరునామా వంటి డాక్యుమెంట్ చేయబడిన కనెక్షన్ వివరాలను పొందుతుంది. ప్రతి క్లయింట్ కాన్ఫిగరేషన్ భాగాన్ని వ్రాయడానికి, విధాన నిర్ణయాన్ని అమలు చేయడానికి లేదా సర్వర్ సొంతమైన స్థితిని నమోదు చేయడానికి ఇది సరైన స్థలం.
వ్యక్తులు దాటవేసే భేదం ఆ హుక్కు మరియు సర్వర్ up హుక్కు మధ్య ఉన్న భేదం. సర్వర్ తన టన్నెల్ పరికరాన్ని తెరిచినప్పుడు up హుక్ మండుతుంది, బహు-క్లయింట్ సర్వర్పై ఇది డీమన్ ప్రారంభంలో ఒకసారి జరుగుతుంది. ఇది ప్రతి లాగిన్కు సంఘటన కాదు, మరియు అక్కడ పెట్టిన కోడ్ వినియోగదారులు కనెక్ట్ అయినప్పుడు కాకుండా సేవ ప్రారంభమైనప్పుడు నడుస్తుంది.
వెబ్ ఇంటర్ఫేస్ ఉన్న పరికరంలో, ఉత్పత్తి చేయబడిన డీమన్ ఫైళ్లను సవరించడానికి బదులు మద్దతు ఉన్న పొడిగింపు విధానాన్ని ఉపయోగించండి. ఉత్పత్తి చేయబడిన ఫైళ్లు తదుపరి సేవ్ సమయంలో తిరిగి వ్రాయబడతాయి, మరియు ఆ పునర్లేఖనం మీ మార్పును అత్యంత దారుణమైన క్షణంలో నిశ్శబ్దంగా తొలగిస్తుంది. పొడిగింపు పాఠ్యం ప్రతిని పరికరం బయట ఉంచండి, తద్వారా firmware నవీకరణ కూడా ఉద్దేశాన్ని కోల్పోదు.
క్లయింట్ వైపు ఎంపిక: స్థానికంగా నడవాల్సిన పని
సంఘం క్లయింట్ టన్నెల్ పరికరం లేచినప్పుడు మరియు మళ్లీ మార్గాలు ఇన్స్టాల్ అయినప్పుడు స్థానిక స్క్రిప్ట్ను నడపగలదు. ఇవి రెండు వేర్వేరు క్షణాలు, మరియు తప్పుదాన్ని ఎంచుకోవడం వల్ల సహాయకుడు ఆధారపడే మార్గం ఉనికిలోకి రాకముందే ప్రారంభమయ్యే సాంప్రదాయ రేస్ ఏర్పడుతుంది.
సహాయకుడు ఆ క్లయింట్పై ఉండాలి, క్లయింట్ను నడిపే ఖాతాకు చదవగలిగి, నడపగలిగి ఉండాలి, మరియు స్పష్టమైన script-security సెట్టింగ్ ద్వారా అనుమతించబడాలి. మీరు నిర్వాహకుడిగా క్లయింట్ను ప్రారంభించినప్పుడు పని చేసే స్క్రిప్ట్ లాగిన్కు ముందున్న సేవ లేదా మరొక వినియోగదారు సెషన్ గురించి ఏమీ చెప్పదు.
పేరు పెట్టడం కూడా ముఖ్యం. up హుక్ పరికర సృష్టికి మరియు route-up మార్గ స్థాపనకు సరిపోతాయి, కానీ ప్రైవేట్ నెట్వర్క్ చేరుకోగలగాల్సిన పని, పరికర సృష్టి అంటే ప్రతి మార్గం, resolver నమోదు మరియు అప్లికేషన్ సిద్ధంగా ఉన్నాయని ఊహించడం బదులు చేరుకోగల సామర్థ్యాన్ని ధృవీకరించాలి.
అమలు చేయగల కోడ్ను push చేయడం ఎంపికల్లో లేకపోవడానికి కారణం
push చేయబడే ఎంపికలు ఉద్దేశపూర్వకంగా పరిమితం చేయబడ్డాయి, మరియు స్క్రిప్ట్లను నడిపే ఎంపికలు సర్వర్ పంపడానికి అనుమతి లేని వర్గాల్లో ఉన్నాయి. ఆ పరిమితి ఉన్నందుకు కారణం, ప్రత్యామ్నాయం ఉంటే రాజీపడిన లేదా తప్పుగా కాన్ఫిగర్ చేయబడిన సర్వర్, ఎప్పుడైనా కనెక్ట్ అయ్యే ప్రతి క్లయింట్పై ఏకపక్ష ఆదేశాలను నడపగలిగేది.
స్థానికంగా స్క్రిప్ట్ అమలును ప్రారంభించడం దాన్ని మార్చదు. మీ script-security సెట్టింగ్ మీరు ఎంచుకున్న స్థానిక స్క్రిప్ట్లను అనుమతిస్తుంది; అది సర్వర్కు కొత్తవి సరఫరా చేసే అధికారాన్ని ఇవ్వదు.
లక్ష్యం కేవలం VPN మార్గాలను ఇన్స్టాల్ చేయడమే అయితే, దూర అమలు పథకాన్ని కనిపెట్టడం బదులు మద్దతు ఉన్న మార్గ కాన్ఫిగరేషన్ను ఉపయోగించండి. లక్ష్యానికి నిజంగా స్థానిక కోడ్ అవసరమైతే, సంస్థ ఎండ్పాయింట్ నిర్వహణ సాధనాల ద్వారా దాన్ని పంపిణీ చేయండి మరియు వినియోగదారు అధికారాలతో నడిచే ఇతర ఏ సాఫ్ట్వేర్లాగానైనా సమీక్షించండి.
రెండు హుక్లలో దేన్నైనా నమ్మే ముందు ఏమి ధృవీకరించాలి
ప్రతి హుక్కు నాలుగు విషయాలు రాయండి: మెషీన్, సంఘటన పేరు, అది నడిచే ఖాతా, మరియు అది ఉత్పత్తి చేయాల్సిన స్థితి మార్పు. తర్వాత కనెక్షన్, పునఃకనెక్షన్ మరియు శుభ్రపరిచే మార్గాన్ని పరీక్షించండి, ఎందుకంటే పునఃకనెక్షన్లో స్థితిని లీక్ చేసే హుక్ ఎప్పుడూ నడవని హుక్ కంటే అధ్వాన్నం.
నిజంగా దాన్ని నడిపే ఖాతా కింద, నిజంగా నడిచే క్షణంలో పరీక్షించండి. openvpn(8) మాన్యువల్ రెండు హుక్ కుటుంబాలను మరియు push పరిమితులను డాక్యుమెంట్ చేస్తుంది; మీరు అమలు చేసే ప్లాట్ఫారమ్ అవి అసలు అందిస్తుందో లేదో డాక్యుమెంట్ చేస్తుంది. ఇంటరాక్టివ్ నిర్వాహక టెర్మినల్లో విజయవంతమయ్యే స్క్రిప్ట్ ఒక ఊహ, ధృవీకరణ కాదు.