OpenVPN client-connect హుక్: మీ చిరునామా నిజంగా ఎక్కడికి వెళ్తుంది

client-connect స్క్రిప్ట్ నుండి చిరునామాను తిరిగి ఇవ్వడం క్లయింట్ IPని సెట్ చేయాలన్నట్లు అనిపిస్తుంది. కానీ అది చేయదు: హుక్ నుండి సర్వర్కు ఉన్న ఏకైక మార్గం ఒక తాత్కాలిక ఫైల్, దాని మార్గం స్క్రిప్ట్ యొక్క చివరి ఆర్గ్యుమెంట్గా వస్తుంది, చిరునామా అక్కడ ifconfig-push సింటాక్స్లో రాయాలి. చిరునామాను ముద్రించే లేదా ఏమీ రాయకుండా సున్నాతో నిష్క్రమించే స్క్రిప్ట్ పూల్ నుండి చిరునామా ఉన్న కనెక్ట్ అయిన క్లయింట్ను సృష్టిస్తుంది, సర్వర్ లాగ్ పూర్తిగా ఆరోగ్యంగా కనిపిస్తుంది.

గందరగోళం సమంజసం, ఎందుకంటే అనేక ఇతర హుక్లు నిష్క్రమణ కోడ్లు లేదా పర్యావరణ వేరియబుల్స్ ద్వారా నిజంగా సమాధానం ఇస్తాయి. ఈ హుక్కు దాని స్వంత ఒప్పందం ఉంది, ఒప్పందం ఫైల్ పేరుతో ప్రారంభమవుతుంది.

హుక్ ఫైల్ను రాస్తుంది, తిరిగి ఇచ్చే విలువను కాదు

ప్రకటన రెండు పంక్తులు: పిలుపును అనుమతించడానికి script-security 2, ఆపై client-connect /etc/openvpn/server/assign-address.sh. క్లయింట్ ప్రామాణీకరించబడినప్పుడు, సర్వర్ ఆ స్క్రిప్ట్ను సృష్టించిన ఫైల్ మార్గాన్ని చివరి ఆర్గ్యుమెంట్గా జోడించి నడుపుతుంది, ప్రకటన తన స్వంత అదనపు ఆర్గ్యుమెంట్లను పంపకపోతే మాత్రమే అది $1 అవుతుంది. ఆ క్లయింట్కు వర్తించే ప్రతిదీ ఆ ఫైల్లో సాధారణ సూచనలుగా, ప్రతి పంక్తికి ఒకటి, కాన్ఫిగరేషన్లో కనిపించే విధంగానే రాయబడుతుంది. తన స్వంత పారామితులను జోడించే ర్యాపర్ స్థానాన్ని కదిలిస్తుంది, సాంప్రదాయ లక్షణం --verbose లాగా కనిపించే మార్గానికి రాసే స్క్రిప్ట్.

నిష్క్రమణ స్థితి ఒప్పందంలోని మరో సగం. సున్నా అంటే అంగీకరించి ఫైల్ను చదువు; మిగతా ఏదైనా కనెక్షన్ను తిరస్కరిస్తుంది, మ్యాప్ చేయని గుర్తింపు నిశ్శబ్దంగా పూల్కు తిరిగి పోకుండా ఈ విధంగానే తిరస్కరించబడుతుంది. విజయాన్ని తిరిగి ఇచ్చే ముందు పూర్తి సూచనను రాయండి, సగం రాసిన ఫైల్ ఎప్పుడూ క్లయింట్ కాన్ఫిగరేషన్ కాకుండా.

రెండు సూచనలు గమనార్హం, ఎందుకంటే అవి మిగతా అన్నింటితో సంకర్షణ చెందుతాయి. ifconfig-push చిరునామాను నిర్ణయిస్తుంది, పంపిన route టన్నెల్ ద్వారా ఏమి చేరుకోవచ్చో క్లయింట్కు చెబుతుంది; మొదటిది తిరిగి ఇచ్చి రెండవది మరిచిపోతే చిరునామా ఉన్నా వెళ్లడానికి చోటు లేని క్లయింట్ లభిస్తుంది. ఫైల్ లోపల క్రమం ముఖ్యం కాదు, పూర్ణత ముఖ్యం. ఏ పీర్ చేరుకోలేని ప్రిఫిక్స్ కోసం మార్గం పంపే హుక్ మరో చివరి నుండి చూసిన అదే తప్పు.

ఇన్పుట్లు పర్యావరణ వేరియబుల్స్ ద్వారా వస్తాయి: common_name, trusted_ip, ifconfig_pool_remote_ip మరియు మిగతావి. వాటిని సర్వర్ వెలుపలి స్ట్రింగ్లుగా పరిగణించండి, ఎప్పుడూ షెల్ ముక్కలుగా కాదు.

చిరునామా మ్యాపింగ్ ఒక విధానం, గణితం కాదు

ఆకర్షణీయమైన చిన్న మార్గం సర్టిఫికెట్ పేరును విశ్లేషించి దాని అంకెలను చివరి ఆక్టెట్గా ఉపయోగించడం. అది కేటాయింపుదారు కాదు, సాధారణ మార్గాల్లో విఫలమవుతుంది: ఒకే ప్రత్యయం ఉన్న రెండు పేర్లు ఢీకొంటాయి, 300తో ముగిసే పేరు చిరునామా కాదు, నిర్వాహకుడు పేరు మార్చిన సర్టిఫికెట్ పరికరాన్ని నిశ్శబ్దంగా కదిలిస్తుంది. ప్రతి కాల్లో సబ్నెట్ సభ్యత్వం, ఉపయోగించగల హోస్ట్ పరిధి, రిజర్వ్ చేసిన చిరునామాలు మరియు ప్రత్యేకతను ధృవీకరించండి, మ్యాపింగ్ను మనిషి చదవగల పట్టికలో ఉంచండి.

పేరును నియంత్రించేవారు చిరునామాను నియంత్రిస్తారు, కాబట్టి ఈ అమరికలో common_name నిజంగా ఏమి సూచిస్తుందో నిర్ణయించండి. username-as-common-name ప్రారంభించినప్పుడు గుర్తింపు లాగిన్, సర్టిఫికెట్ సబ్జెక్ట్ కాదు. ఆ విలువను ఎప్పుడూ షెల్ మూల్యాంకనానికి పంపకండి, క్లయింట్ ఫైల్ మార్గాన్ని ప్రభావితం చేయనివ్వకండి.

రిజిస్ట్రీ ఆధారిత కేటాయింపుదారు సమకాలీనతను తట్టుకోవాలి. చిరునామాను పరమాణు రీతిలో రిజర్వ్ చేయండి, సగం కాన్ఫిగర్ అయిన క్లయింట్ను అనుమతించకుండా విఫలమైన రాతను నిర్వహించండి, ప్రతి కేటాయింపును దానిని కలిగి ఉన్న కనెక్షన్తో ట్యాగ్ చేయండి, పాత సెషన్ ఆలస్యంగా డిస్కనెక్ట్ అయినప్పుడు కొత్తది ఇప్పటికే కలిగి ఉన్న చిరునామాను విడుదల చేయలేకుండా. ఒక పూల్ను పంచుకునే అనేక సర్వర్ ఇన్స్టాన్సులు ఈ అవసరాన్ని ఐచ్ఛికం కాకుండా మరింత తీవ్రం చేస్తాయి.

ifconfig-push అర్థం ఏమిటో టోపాలజీ నిర్ణయిస్తుంది

10.77.0.0/24పై topology subnet తో, ifconfig-push 10.77.0.20 255.255.255.0 ఒక చిరునామా మరియు దాని నెట్మాస్క్. topology net30 కింద రెండవ ఆర్గ్యుమెంట్ మాస్క్ కాదు, పీర్ చిరునామా, కాబట్టి సబ్నెట్ రూపాన్ని net30 సర్వర్కు కాపీ చేస్తే కనెక్ట్ అయ్యే కానీ ట్రాఫిక్ పంపలేని క్లయింట్ లభిస్తుంది. టోపాలజీని ఉద్దేశపూర్వకంగా మార్చండి, ఉదాహరణ స్థిరంగా కనిపించడానికి ఎప్పుడూ కాదు. ఇప్పటికే net30 నడుపుతున్న సర్వర్కు పాత చిరునామాలపై సజీవ క్లయింట్లు ఉన్నారు, కాబట్టి మార్పు నిర్వహణ విండోతో కూడిన వలస, ఒక పంక్తి సవరణ కాదు.

స్థిర చిరునామాలు డైనమిక్ పూల్ వెలుపల మరియు ప్రతి ఇతర స్థిర కేటాయింపు వెలుపల ఉండాలి, సాధారణ client-config-dir ఫైల్లు ఇచ్చేవి కూడా. రెండు యంత్రాంగాలు వేర్వేరు క్లయింట్లకు ఒకే చిరునామాను ఉత్పత్తి చేయగలిగితే, వాటిలో ఒకటి చివరికి అలా చేస్తుంది.

అది నమ్మే ముందు నాలుగు సందర్భాలను పరీక్షించండి

అదే తనిఖీలను మ్యాప్ చేసిన గుర్తింపు, చేయని గుర్తింపు, పునఃకనెక్షన్ మరియు అనుకరణ చేసిన రిజిస్ట్రీ వైఫల్యంపై నడపండి. openvpn --config client.ovpn --verb 4 కేటాయించిన చిరునామాను push ప్రతిస్పందనలో చూపిస్తుంది, సర్వర్పై grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log నిజంగా ఏమి పంపబడిందో నిర్ధారిస్తుంది. మ్యాప్ చేయని గుర్తింపుకు ఆశించిన ఫలితం తిరస్కరించిన కనెక్షన్, పూల్ చిరునామా కాదు.

ఆపై డీమన్ ఆ తాత్కాలిక ఫైల్లను రాసే డైరెక్టరీని పరిశీలించండి. స్క్రిప్ట్ తగ్గించిన సేవా సందర్భంలో నడుస్తుంది, కాబట్టి root రాయగలిగే కానీ డీమన్ రాయలేని మార్గం ప్రతి కనెక్షన్ను లాగ్లో అనేక పంక్తుల కింద పాతిపెట్టిన అనుమతి లోపంతో తిరస్కరణగా మారుస్తుంది.

కేటాయింపు అధికారం కాదు: పిన్ చేసిన చిరునామా ఇప్పటికీ సర్వర్ వెనుక ఉన్న ప్రతి గమ్యానికి ప్రాప్యత ఇవ్వదు. రూటింగ్ మరియు ఫైర్వాల్ విధానాన్ని దాని స్వంత పొరలో ఉంచండి, మీరు ఇప్పుడే నిర్ణయించిన చిరునామాకు వ్యతిరేకంగా దాన్ని ధృవీకరించండి.