ఒక OpenVPN క్లయింట్పై రెండు సేవా చిరునామాలు: iroute మరియు lo

అప్లికేషన్ తన టన్నెల్ చిరునామాపై స్పందిస్తుంది, మరియు మీరు దాని కోసం నమోదు చేసిన చిరునామా ఎక్కడికీ వెళ్లదు. OpenVPN లాగ్లో ఏదీ ఫిర్యాదు చేయదు, పీర్ కనెక్ట్ అయినట్లు కనిపిస్తుంది, హబ్ సరిగ్గా ఒక క్లయింట్ను జాబితా చేస్తుంది. ఖాళీ ఏమిటంటే, క్లయింట్పై రెండవ చిరునామా రెండు వేర్వేరు వాస్తవాలు: హోస్ట్ దానిని కలిగి ఉండాలి, ఏ పీర్ దానిని కలిగి ఉందో హబ్ తెలుసుకోవాలి. ఒకదాన్ని మరొకటి లేకుండా నిర్వహిస్తే, ట్రాఫిక్ హబ్లో చనిపోతుంది లేదా ఇంటికి మార్గం లేకుండా చేరుతుంది.

ఉపనామం స్థానికం, యాజమాన్యం దూరం

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

క్లయింట్పై చిరునామా హోస్ట్కు చెందుతుంది, భౌతిక లింక్పై ఎప్పటికీ కనిపించకూడని సేవా గుర్తింపుకు loopback సహజ నివాసం. హబ్లో పీర్-నుండి-ప్రిఫిక్స్ మ్యాపింగ్ సర్వర్ మాత్రమే చదివే ప్రత్యేక ప్రకటన. ఏ రికార్డు మరొకదాన్ని సూచించదు.

మీ నోట్స్లో కూడా రెండు పరిధులను వేరుగా ఉంచండి. ఉదాహరణలోని చిరునామాలు డాక్యుమెంటేషన్ విలువలు, వాటిని నిజమైన LANతో అతివ్యాప్తి చేయడం పనిచేస్తున్న సెటప్ను విరిగినట్లు కనిపించేలా చేసే వేగవంతమైన మార్గం.

క్లయింట్పై చిరునామాను శాశ్వతంగా జోడించండి

సేవా చిరునామాను హోస్ట్ ప్రిఫిక్స్తో loopbackపై ఉంచండి, హోస్ట్ దానిని చేరుకోవాల్సిన సబ్నెట్గా కాకుండా స్థానిక ఇన్పుట్గా పరిగణిస్తుంది. ip address add 10.66.0.10/32 dev lo ఒక చిరునామా కోసం అలా చేస్తుంది, రెండవ చిరునామా కోసం ఆదేశాన్ని పునరావృతం చేయడం రెండు సేవలను నమూనా చేస్తుంది.

దానిని ఒకసారి పరీక్షగా అమలు చేయండి, ఆపై హోస్ట్ నెట్వర్క్ కాన్ఫిగరేషన్ను కలిగి ఉన్నదానిలోకి తరలించండి, ఎందుకంటే రన్టైమ్ జోడింపు రీబూట్లో అదృశ్యమవుతుంది మరియు మళ్లీ కనెక్ట్ అయ్యే మధ్య నకళ్లు పోగవుతాయి. నెట్వర్క్ తర్వాత క్రమబద్ధీకరించిన systemd యూనిట్ ఒక ఎంపిక, పంపిణీ నెట్వర్క్ మేనేజర్ మరొకటి. మీరు ఏది ఎంచుకున్నా, అప్లికేషన్ బైండ్ అయ్యే ముందు చిరునామా ఉండాలి, లేకపోతే సేవ తప్పు సాకెట్పై లేస్తుంది. మాన్యువల్ ఆదేశం తర్వాత కాదు, రీబూట్ తర్వాత ip address show dev lo తో ధృవీకరించండి.

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

హబ్ నిజంగా చదివే CCD ఫైల్లో దానిని కోరండి

సర్వర్పై యాజమాన్య ప్రకటన ప్రామాణీకృత సాధారణ పేరు ద్వారా ఎంచుకున్న ప్రతి-క్లయింట్ ఫైల్లోకి వెళ్తుంది, client-config-dir పేరు పెట్టిన డైరెక్టరీలో. లైన్ iroute 10.66.0.10 255.255.255.255, ప్రతి చిరునామాకు ఒకటి, ఆ గమ్యానికి ఏ పీర్ ట్రాఫిక్ పొందాలో సర్వర్కు చెబుతుంది.

రెండు వివరాలు దీన్ని నిశ్శబ్దంగా విరుస్తాయి. ఫైల్ పేరు సర్వర్ నిజంగా ఉపయోగించే పేరుతో సరిపోలాలి, username-as-common-name ఆటలో ఉన్నప్పుడు అది భిన్నంగా ఉంటుంది. మరియు iroute క్లయింట్ కాన్ఫిగరేషన్ డైరెక్టరీ కాన్ఫిగర్ చేసిన TUN మోడ్లో మాత్రమే పనిచేస్తుంది, కాబట్టి బ్రిడ్జ్ అమలులో అదే లైన్ ఏమీ చేయదు. ఉన్న ఫైల్కు లైన్లు జోడించండి, దాన్ని భర్తీ చేయవద్దు, ఎందుకంటే అది ఇప్పటికే స్థిర చిరునామా లేదా push ఎంపికలను కలిగి ఉండవచ్చు. OpenVPN 2.6 సూచన డైరెక్టరీ మరియు యాజమాన్య ఆదేశం రెండింటినీ నమోదు చేస్తుంది.

హబ్ స్వంత కెర్నల్కు కూడా ఆ గమ్యాలకు మార్గం అవసరం, స్థానికంగా ఉత్పత్తి అయిన ట్రాఫిక్ టన్నెల్ ప్రక్రియలోకి ప్రవేశించడానికి. సర్వర్ కాన్ఫిగరేషన్లో route 10.66.0.10 255.255.255.255 సర్వర్ స్వయంగా సృష్టించే ట్రాఫిక్ను కవర్ చేస్తుంది, ఇతర క్లయింట్లు గమ్యాన్ని తామే నేర్చుకోవడానికి push "route 10.66.0.10 255.255.255.255" అవసరం.

రూటింగ్ మరియు అనుమతి వేరుగా ఉంటాయి. నెట్టబడిన మార్గం క్లయింట్కు ప్యాకెట్లను ఎక్కడ పంపాలో చెబుతుంది, ఏమీ ఇవ్వదు; సేవ ఇంకా పిలిచే వ్యక్తిని తన నిబంధనలపై అంగీకరించాలి.

ఇన్పుట్ విధానం మరియు ప్రతిస్పందన మార్గాన్ని తనిఖీ చేయండి

ఉపనామానికి చిరునామా చేసిన ప్యాకెట్ యజమాని హోస్ట్కు స్థానిక ఇన్పుట్గా చేరుతుంది, కాబట్టి ప్రశ్న ఏమిటంటే స్థానిక ఫైర్వాల్ ఆ మూలాన్ని మరియు పోర్టును అనుమతిస్తుందా. మొత్తం చిరునామాను తెరవడం బదులు VPN మూల పరిధి నుండి నిర్దిష్ట సేవా పోర్టును అనుమతించండి.

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

అదే పోర్ట్పై వేరే చిరునామాకు బద్ధమైన రెండవ శ్రోతను గమనించండి, ఎందుకంటే కెర్నల్ సరిపోలే సాకెట్కు అందిస్తుంది మరియు ఫలితాలు యాదృచ్ఛికంగా కనిపిస్తాయి. ss -lntp తో తనిఖీ చేయండి మరియు బద్ధమైన చిరునామా సేవా ఉపనామం అని నిర్ధారించండి. ఇక్కడ మూల NAT అవసరం లేదు, దాన్ని జోడించడం మీ లాగ్లు ఆధారపడే పిలిచే వ్యక్తి గుర్తింపును దాచుతుంది.

చిరునామాలు మరియు యాజమాన్యాన్ని విడివిడిగా పరీక్షించండి

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

కనెక్షన్ తర్వాత కూడా మిగిలే వైఫల్య విధానాలను తనిఖీ చేయండి: టన్నెల్ కింద ఉన్నప్పుడు కూడా ఉపనామం కేటాయించబడి ఉంటుంది, పీర్ లేనప్పుడు కూడా హబ్ తన మార్గాన్ని ఉంచుకుంటుంది. ఏ వస్తువు ఒంటరిగా సేవ చేరుకోగలదని నిరూపించదు, అందుకే రెండు దశల పరీక్ష ల్యాప్టాప్ నుండి ఒక పింగ్ కంటే మెరుగైనది.