ప్రతి OpenVPN పీర్కు remote లైన్ అవసరమా? సరిగ్గా కాదు
remote మొదటి ప్యాకెట్ ఎక్కడికి వెళుతుందో చెబుతుంది; అది క్లయింట్, సర్వర్ లేదా TLS పాత్రను ఎంచుకోదు. రెండు వైపులకూ కాపీ చేయడానికి ముందు అమరికను చదవండి.
రెండు పీర్ కాన్ఫిగరేషన్లను పక్కపక్కన పోల్చారు, ఒకటి remote లైన్ కలిగి ఉంది మరొకటి లేదు, మరియు వాటిలో ఒకటి పాడైందని నిర్ణయం. ఆ అనుమానం విశ్లేషించదగినంత తరచుగా తప్పు. ఈ సూచన మొదటి ప్యాకెట్ ఎక్కడికి పంపాలో వివరిస్తుంది. ప్రక్రియ ప్రారంభించే క్లయింట్గా లేదా వేచి ఉండే గేట్వేగా పనిచేస్తుందా అని ఇది ఎంచుకోదు, ఏ వైపు మరొకరికి తన గుర్తింపును నిరూపిస్తుందో కూడా నిర్ణయించదు.
remote వాస్తవంగా ఏమి నిర్దేశిస్తుంది
remote నమోదు ఒక హోస్ట్ను, ఐచ్ఛికంగా పోర్ట్ మరియు రవాణాను, మరియు ఐచ్ఛికంగా క్రమంగా ప్రయత్నించాల్సిన అలాంటి అనేక నమోదులను పేర్కొంటుంది.
దాని లేకపోవడానికి అనిశ్చితం కాని నిర్దిష్ట అర్థం ఉంది: ప్రక్రియ వేచి ఉంటుంది మరియు ఆ పీర్ ధృవీకరించుకోనంత వరకు ఏదైనా చిరునామా నుండి వచ్చే ప్యాకెట్లపై పనిచేయదు. అందువల్ల సంచరించే వినియోగదారులకు సేవ చేసే గేట్వే వారిలో ఎవరినైనా ముందుగానే పేర్కొనడానికి కారణం లేదు.
నమోదును చిరునామా సంబంధంగా చదవండి. దూరపు చివర నమ్మదగినదా అని సర్టిఫికెట్లు మరియు ధృవీకరణ ఎంపికలు సమాధానం ఇస్తాయి, చిరునామా రాయబడిందనే వాస్తవం కాదు.
మూడు అమరికలు సమాధానాన్ని నిర్ణయిస్తాయి
సంచరించే క్లయింట్కు గమ్యం అవసరం, ఎందుకంటే అది ప్రారంభించాలి మరియు అది లేకుండా గేట్వే ఎక్కడ ఉందో దానికి తెలియదు. బహు-క్లయింట్ గేట్వేకు ప్రతి వినియోగదారుకు గమ్యం అవసరం లేదు, ఎందుకంటే క్లయింట్లు వచ్చి ధృవీకరించుకుంటాయి. తెలిసిన చివరలు ఉన్న ఉద్దేశపూర్వక రెండు-పీర్ లింక్కు ఒక వైపు, రెండు వైపులా లేదా ఏ వైపూ గమ్యం ఉండవచ్చు, ఏ వైపు ప్రారంభిస్తుందనే దానిపై ఆధారపడి.
స్థిర క్లయింట్ చిరునామాను సాధారణ గేట్వేలో అతికించడం ఆ వర్గాలను నిర్లక్ష్యం చేయడం నుండి వచ్చే పొరపాటు. ఇది చిరునామా నమోదైన ఒకే పీర్కు పనిచేస్తుంది మరియు మిగతా అందరినీ తప్పుదారి పట్టిస్తుంది.
సూచనలో కాన్ఫిగరేషన్ను బహు-క్లయింట్ సర్వర్గా మార్చేది ఏదీ లేదు, దాని ఉనికిలో సర్వర్ పాత్రను నిరోధించేది కూడా లేదు. OpenVPN 2.6 సూచన ఐచ్ఛిక ఆర్గ్యుమెంట్లను మరియు remote లేనప్పుడు ప్రవర్తనను విడిగా నమోదు చేస్తుంది, ఇది అవి ఎంత స్వతంత్రమైనవో తెలిపే సూచన.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
రవాణా పాత్రలు మరో అక్షం
TCP లో ఒక వైపు వేచి ఉంటుంది మరియు మరొకటి కాల్ చేస్తుంది. ఇవి గమ్యం నుండి వేరైన సూచనలు, వాటిని కలపడం రెండూ వేచి ఉండే లేదా రెండూ కాల్ చేసే జంటను సృష్టిస్తుంది.
TCP మూల-ఫిల్టర్ పాత్ర కూడా ఉంది, అందుకే సర్వర్ ఎప్పటికీ remote కలిగి ఉండకూడదనే చదునైన ప్రకటన తప్పు.
UDP లో ఏర్పాటు చేయాల్సిన కనెక్షన్ లేదు, కాబట్టి రెండు చివరలు సంబంధిత UDP రవాణాను ఉపయోగిస్తాయి మరియు సూచన ఎక్కడ లక్ష్యంగా పెట్టుకోవాలో మాత్రమే చెబుతుంది. ధృవీకరించబడిన పీర్ చిరునామా మార్పులను మరిన్ని నమోదులు జోడించడం ద్వారా కాకుండా ప్రత్యేక ప్రవర్తన నిర్వహిస్తుంది. రవాణాను సరిగ్గా చేయడం గమ్యం అర్థవంతంగా ఉండటానికి ముందస్తు షరతు, రెండింటినీ కలపడం నమ్మదగినట్లు కనిపించే మరియు ఎప్పటికీ హ్యాండ్షేక్ పూర్తి చేయని కాన్ఫిగరేషన్లను సృష్టిస్తుంది.
remote లేకపోవడం తెరిచిన తలుపు ఎందుకు కాదు
గమ్యం లేని ప్రక్రియ కూడా ధృవీకరించుకోని పీర్ల ట్రాఫిక్ను తిరస్కరిస్తుంది, లేని లైనును అందరికీ తెరిచిన శ్రోతగా చదివేటప్పుడు ప్రజలు దాటవేసే భాగం ఇదే.
ధృవీకరణ మరియు గమ్యం స్వతంత్రమైనవి, నమ్మకానికి మొదటిదే ముఖ్యం.
వ్యతిరేక పొరపాటు మరింత ప్రమాదకరం. స్థిర మూల చిరునామా నిర్దిష్టంగా మరియు తనిఖీ చేయడానికి సులభంగా ఉండటం వల్ల యాక్సెస్ నియంత్రణలా అనిపించవచ్చు, కానీ మరొక వైపు ఎవరు ఉన్నారనే దాని గురించి ఏమీ నిరూపించదు. సర్టిఫికెట్ ధృవీకరణను ఉంచండి, సర్టిఫికెట్ను దాని పాత్రకు కలిపే గుర్తింపు తనిఖీలను కూడా ఉంచండి. వాటిని చిరునామా సరిపోలికతో భర్తీ చేయడం నిజమైన నియంత్రణను దాని రూపంతో మారుస్తుంది.
కాన్ఫిగరేషన్ ఏమి ఊహిస్తుందో రాయండి
ప్రతి వైపుకు మూడు విషయాలను నమోదు చేయండి: మొదటి ప్యాకెట్ పీర్ను ఎలా చేరుతుంది, ఏ వైపు రవాణాను అంగీకరించగలదు, మరియు ప్రతి వైపు మరొకదాని గురించి ఏమి ధృవీకరిస్తుంది.
ఆ ఊహలే రూపకల్పన. సూచనలు వాటి అక్షరక్రమం మాత్రమే.
రెండు ఫైళ్లు భిన్నంగా ఉంటే, ఒకటి తప్పు అని ఊహించడం బదులు అవి వేర్వేరు ఊహలను వ్యక్తపరుస్తున్నాయా అని తనిఖీ చేయండి. సమరూప ఫైల్ జంట పనిచేసే సొరంగానికి అవసరం కాదు సరిపోదు కూడా, అసమరూపతే తరచుగా టోపోలజీని పనిచేయించే భాగం.