OpenVPN క్లయింట్లను Cloudflare ద్వారా రూట్ చేయాలా? మొదట పాత్రను తనిఖీ చేయండి
పరికర క్లయింట్ రూటర్ కాదు. Cloudflare పాత్ర ఇతర హోస్ట్ల ప్యాకెట్లను ఫార్వర్డ్ చేస్తుందని నిర్ధారించి, ఆపై సర్వర్ యొక్క స్వంత టన్నెల్ను దాని పాత మార్గంలో ఉంచండి.
మీ దగ్గర నడుస్తున్న OpenVPN సర్వర్ మరియు Cloudflare యొక్క పరికర సాఫ్ట్వేర్ను కూడా అమలు చేసే హోస్ట్ ఉన్నాయి, తదుపరి స్పష్టమైన దశ క్లయింట్ ట్రాఫిక్ను అక్కడికి పంపడం అనిపిస్తుంది. ఒక మెషీన్పై రెండు నడుస్తున్న కనెక్షన్లు కలిసి ట్రాన్సిట్ గేట్వే కావు. లోపించినది ఇతరులకు చెందిన ప్యాకెట్లను ఫార్వర్డ్ చేయడానికి పత్రబద్ధమైన పాత్ర, మరియు ఆ ప్యాకెట్లు వచ్చినప్పుడు వాటిని వర్గీకరించే విధానం.
ఏ నియమానికైనా ముందు నాలుగు ప్రశ్నలు: ఏ ట్రాఫిక్ లోపలికి వస్తుంది, అది తర్వాత ఎక్కడికి వెళ్తుంది, జవాబులు తిరిగి వచ్చే మార్గాన్ని ఎలా కనుగొంటాయి, మరియు ఆ రెండవ మార్గం విఫలమైనప్పుడు డిజైన్ ఏమి చేస్తుంది. మొదటి రెండు సామర్థ్య ప్రశ్నలు.
ఒక హోస్ట్పై రెండు సేవలు ట్రాన్సిట్ మార్గం కావు
పరికర క్లయింట్ తాను నడిచే మెషీన్లో ఉత్పన్నమయ్యే ట్రాఫిక్ను నిర్వహించడానికి నిర్మించబడింది. ఇది పేరు పరిష్కారాన్ని లేదా ఎంచుకున్న అప్లికేషన్ ట్రాఫిక్ను అడ్డుకుని తన స్వంత టన్నెల్ ద్వారా పంపుతుంది, దాని విధానం ఆ పరికర వినియోగదారు మరియు ఆ పరికర ప్రక్రియల కోసం వ్రాయబడింది. OpenVPN క్లయింట్ నుండి ఫార్వర్డ్ చేయబడిన ప్యాకెట్ స్థానిక అవుట్పుట్ కాదు, కాబట్టి అదే నియమాలు దాన్ని వర్గీకరించవు. ఇది విస్తృత నియమంతో కప్పగలిగే కాన్ఫిగరేషన్ వివరం కాదు, ఎందుకంటే సాఫ్ట్వేర్ ప్యాకెట్ను అసలు చూస్తుందో లేదో ఇదే నిర్ణయిస్తుంది.
అందుకే డిజైన్ ప్రశ్న సామర్థ్య ప్రశ్న. గానీ ఇన్స్టాల్ చేసిన ఉత్పత్తికి ఇతర నెట్వర్క్ల కోసం ట్రాఫిక్ను ఫార్వర్డ్ చేసే పత్రబద్ధమైన పాత్ర ఉంది, లేదా ట్రాన్సిట్ పని పూర్తిగా వేరే ప్రదేశానికి చెందుతుంది.
Cloudflare యొక్క ఏ పాత్ర ఫార్వర్డ్ చేయడానికి అనుమతించబడింది
Cloudflare యొక్క పరికర క్లయింట్ పరిధిలో భిన్నమైన మోడ్లను అందిస్తుంది: పేరు పరిష్కారం మాత్రమే, పరికరం నుండి ట్రాఫిక్, మరియు కొన్నిసార్లు రెండూ. ఆ మోడ్లలో ఏదీ మరొక టన్నెల్ ద్వారా వచ్చే ప్రైవేట్ పరిధికి హోస్ట్ను రూటర్గా మార్చదు. అంకిత రూటింగ్ పాత్ర తన స్వంత కనెక్టర్, నమోదు మరియు నెట్వర్క్ మోడల్ కలిగిన ప్రత్యేక ఉత్పత్తి.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
దాని చుట్టూ మార్గాలను రూపకల్పన చేయడానికి ముందు ఇన్స్టాల్ చేసిన పాత్రను తనిఖీ చేయండి. కనెక్టర్ ఏ ఇంటర్ఫేస్ను సృష్టిస్తుంది, అది నిర్దిష్ట ప్రిఫిక్స్లు లేదా డిఫాల్ట్ మార్గాన్ని ప్రకటిస్తుందా, మరియు స్థానిక విధానం స్థానిక ప్యాకెట్లతో పాటు ఫార్వర్డ్ చేసిన ప్యాకెట్లకు కూడా వర్తిస్తుందా అని చదవండి. స్థానిక ట్రాఫిక్ మాత్రమే నిర్వహించబడితే, అనువాద నియమం ఎలా వ్రాసినా OpenVPN సర్వర్ ట్రాన్సిట్ పాయింట్ కాలేదు.
ఇక్కడే పబ్లిక్ ఎగ్రెస్ అవసరాన్ని ఖచ్చితంగా తెలియజేయాలి. ఫార్వర్డ్ చేసిన క్లయింట్ ట్రాఫిక్ కోసం Cloudflare అందించే ఎగ్రెస్ ఒక నిర్దిష్ట వినియోగ సందర్భం, మరియు మీకు నిజంగా ఉన్న సేవకు వ్యతిరేకంగా దాన్ని నిర్ధారించాలి.
బయటి టన్నెల్ను కొత్త మార్గం నుండి స్వతంత్రంగా ఉంచండి
కొత్త ఇంటర్ఫేస్ వైపు డిఫాల్ట్ మార్గాన్ని జోడించిన క్షణమే సర్వర్ యొక్క స్వంత బయటకు వెళ్లే ట్రాఫిక్ దాని కోసం పోటీ పడటం ప్రారంభమవుతుంది, అందులో OpenVPN క్లయింట్లకు ఇచ్చే జవాబులు మరియు మెషీన్కు మీ SSH సెషన్ కూడా ఉంటాయి. సాధారణ లక్షణం స్థాపించబడి తర్వాత చనిపోయే టన్నెల్, లేదా మార్పు పని చేసినట్లు కనిపిస్తున్నప్పుడు బయట లాక్ అయ్యే నిర్వాహకుడు. ఎండ్పాయింట్ కోసం ip route get ను ముందు మరియు తర్వాత పోల్చండి, సర్వర్ యొక్క స్వంత రవాణాను అది ఉన్న చోటే ఉంచడానికి విధాన ఆధారిత రూటింగ్ లేదా హోస్ట్ మార్గాన్ని ఉపయోగించండి. ఆ పోలికను మెషీన్ నుండే నిర్వహించండి, ఎందుకంటే సర్వర్ తన మార్గం గురించి తన దృష్టే ముఖ్యం.
సర్వర్ యొక్క పబ్లిక్ చిరునామా కోసం మినహాయింపు మాత్రమే సరిపోదు, ఎందుకంటే ప్రతి దూర నిర్వాహకుడి తిరిగి వచ్చే మార్గం వేరే ప్రవాహం. ఆ ప్రవాహాలలో ఏది మార్పును తట్టుకోవాలో నిర్ణయించి, మొదటిది మిగతావాటిని కవర్ చేస్తుందని ఊహించడం బదులు ప్రతి ఒక్కటీ ధృవీకరించండి.
ఫార్వర్డింగ్ మరియు అనువాదాన్ని ఒకే ప్రవాహానికి పరిమితం చేయండి
స్వీకరించిన ప్యాకెట్లు స్థానిక అవుట్పుట్ మార్గాన్ని కాదు, ఫార్వర్డింగ్ మార్గాన్ని అనుసరిస్తాయి, కాబట్టి ముఖ్యమైన నియమం forward హుక్లో నివసిస్తుంది. తదుపరి ఇంటర్ఫేస్కు అనువాదం అవసరమైన చోట, మూలాన్ని క్లయింట్ పూల్కు, గమ్యాన్ని అనుమతించిన దానికి, ఎగ్రెస్ను ఆ ఒకే ఇంటర్ఫేస్కు పరిమితం చేయండి. ఇంటర్ఫేస్కు మాత్రమే కట్టుబడిన masquerade నియమం తనంతట తాను ఏ మార్గాన్ని ఎంచుకోదు మరియు మరే ఇతర ఫిల్టర్ను దాటి ఫార్వర్డింగ్ను అనుమతించదు.
విఫలమైనప్పుడు మూసుకుపోయే ప్రవర్తనను ముందుగానే నిర్ణయించి, తర్వాత పరీక్షించండి. తదుపరి మార్గాన్ని ఆపి, క్లయింట్లు నిశ్శబ్దంగా సాధారణ అప్లింక్కు తిరిగి వెళ్లడం బదులు ఉద్దేశించిన ఎగ్రెస్ను కోల్పోతారని నిర్ధారించండి, ఎందుకంటే ట్రాఫిక్ తప్పు తలుపు ద్వారా బయటకు వెళ్లే వరకు ఎవరూ గమనించని ఫలితం అదే. పేరు పరిష్కారం మరియు IPv6 కోసం తనిఖీని పునరావృతం చేయండి, ఎందుకంటే v4 కోసం మాత్రమే ఉన్న నియమాల సమితి v6 మార్గాన్ని తెరిచి ఉంచుతుంది.
మీరు ఆగిన నాలుగు జవాబులను మరియు ప్రతి దాన్ని నిరూపించే పరిశీలనను రాయండి. మీరు వివరించగల ట్రాన్సిట్ మార్గమే తదుపరి సంఘటన సమీక్షలో మీరు రక్షించగల మార్గం.