కేంద్ర-శాఖ మరియు పూర్తి మెష్: మీ సైట్లకు ఏ VPN నిర్మాణం సరిపోతుంది
పని చేస్తున్న రెండు టన్నెల్లు ఒక నిర్మాణం కాదు. కేంద్రం, మెష్ లేదా కొన్ని నేరుగా లింకులతో కూడిన కేంద్రం ఎంచుకునే ముందు ప్రయాణ మార్గం, వైఫల్య ప్రవర్తన, మార్పు వ్యయాన్ని పోల్చండి.
రెండు శాఖ కార్యాలయాలు రోజంతా ఒకదానితో ఒకటి మాట్లాడుకుంటాయి, వాటి మధ్య టన్నెల్ మరో ప్రాంతంలోని డేటా సెంటర్ గుండా మళ్లీ తిరుగుతుంది. ప్రతి అభ్యర్థన ఆ మళ్లింపు కోసం రెండుసార్లు చెల్లిస్తుంది, ఫైల్ సింక్ తప్పుగా అనిపించే వరకు ఎవరూ గమనించరు. నిర్మాణ ప్రశ్న అసలు ఇక్కడే మొదలవుతుంది: ఏ రేఖాచిత్రం ఎక్కువ స్థితిస్థాపకంగా కనిపిస్తుందని కాదు, మీరు ఏ ట్రాఫిక్ నమూనా కోసం చెల్లిస్తున్నారని. రెండు డిజైన్లూ పని చేస్తాయి, వేర్వేరు విధాలుగా, వేర్వేరు ఖర్చులతో విఫలమవుతాయి.
మిగతా ఏదైనా ముందు పీర్ సంబంధాలను లెక్కించండి
N సైట్లు ఉంటే, పూర్తి మెష్కు N గుణించి N మైనస్ ఒకటి, రెండుతో భాగించినంత మంది టన్నెల్లు కావాలి; కేంద్రానికి N చాలు. ఐదు సైట్లలో అది పది మరియు ఐదు, ఇది ఇంకా నిర్వహణీయంగా అనిపిస్తుంది. పదిహేనులో అది 105 మరియు పదిహేను, ఇక్కడ భేదం గణితం కాదు, సిబ్బంది.
ఆ ప్రతి సంబంధం మీరు యాజమాన్యం చేయాల్సిన స్థితిని మోస్తుంది. IPsec లో అర్థం ఒక భద్రతా సంఘం, ఒక గుర్తింపు, ఒక కీ లేదా ధృవపత్రం, చనిపోయిన పీర్ గుర్తింపు, ప్రతి రిమోట్ ప్రిఫిక్స్కు కనీసం ఒక మార్గం. WireGuard లో అర్థం ఒక పబ్లిక్ కీ మరియు ప్రతి పీర్కు ఒక AllowedIPs బ్లాక్; ఇది పీర్కు పీర్ తక్కువ ఖర్చు, కానీ కనుగొనడం అసలు లేదు: కొత్త సైట్ అంటే ఇప్పటికే ఉన్న ప్రతి దానిపై కాన్ఫిగరేషన్ మార్పు.
నిర్ణయించేది రేఖాచిత్రం కాదు, ట్రాఫిక్ మిశ్రమం
శాఖ ట్రాఫిక్ ఎక్కువగా కేంద్ర ERP లేదా ఫైల్ క్లస్టర్కు అభ్యర్థనలు అయితే, కేంద్రం రాజీ కాదు, అదే సరైన ఆకారం: ట్రాఫిక్ ఇప్పటికే అక్కడికే వెళ్లాలని ఉంది, ఒక విధాన బిందువును ఆడిట్ చేయడం జంటవారీ నియమాల మెష్ కంటే సులభం. శాఖలు ఒకదానితో ఒకటి డేటా మార్పిడి చేసుకున్నప్పుడు మెష్ తన సంక్లిష్టతకు విలువ సంపాదిస్తుంది: రెండు కార్యాలయాల మధ్య ప్రతిరూపణ, సైట్ల మధ్య వాయిస్, డజను మంది ఇంజనీర్లు రోజంతా తెరిచే CAD షేర్.
ఇబ్బందికర సందర్భాలు వీటి మధ్య ఉంటాయి, అవే మెజారిటీ. సంస్థ చార్టు నుండి ఊహించడం కంటే వాదించే ముందు కొలవండి.
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
పట్టికను నియమంగా కాదు, సమబలం బ్రేకర్గా చదవండి. నాలుగింటిలో మూడు వరుసలు ఒక వైపు సూచిస్తే సాధారణంగా డిజైన్ అక్కడే నిర్ణయమవుతుంది; చీలిక అంటే హైబ్రిడ్, పరిపక్వ నెట్వర్క్లు చివరికి అదే నడుపుతాయి.
ముందుకు పంపమని కేంద్రానికి చెప్పాలి
పని చేస్తున్న రెండు స్పోక్-టు-హబ్ టన్నెల్లు స్పోక్-టు-స్పోక్ ప్రాప్యతను సృష్టించవు. కేంద్రంలో IP ఫార్వార్డింగ్ ప్రారంభమై ఉండాలి, ప్రతి స్పోక్ నెట్వర్క్కు ఒక మార్గం, ఆ ట్రాన్సిట్ను అనుమతించే ఒక ఫైర్వాల్ నియమం, తిరిగి వచ్చే మార్గం లెక్కించబడాలి; ప్రతి స్పోక్కు మరో సైట్ ప్రిఫిక్స్లకు ఒక మార్గం కావాలి. Linux కేంద్రంలో అది net.ipv4.ip_forward=1 మరియు ఆ జోడీని నిశ్శబ్దంగా రాల్చని FORWARD చైన్, విధాన ఆధారిత IPsec లో అది రెండు చివరల్లో రిమోట్ స్పోక్ సబ్నెట్ను జాబితా చేసే ట్రాఫిక్ సెలెక్టర్లు. strongSwan ఫార్వార్డింగ్ గమనికలు కెర్నల్ మరియు ఫైర్వాల్ వైపును కవర్ చేస్తాయి, ఆ పొర మీకు మిస్ అయినప్పుడు. ఒక చవకైన పరీక్ష: ఒక స్పోక్ నుండి మరో దాని సేవకు ట్రాఫిక్ పంపి కేంద్ర కౌంటర్లను చూడండి; ఎప్పుడూ పెరగని నియమం అంటే మార్గం కాదు, క్రమం తప్పు.
కేంద్ర విధానం కూడా ఉపయోగకరమైన భాగం. శాఖలు ఒకదానికొకటి చేరకుండా పంచుకున్న సేవలను చేరుకోవచ్చు, ఆ ప్రాప్యత మాత్రికను స్పష్టంగా రాయడం విలువైనది. ఎవరైనా చదవగల నియమానికి తప్పిపోయిన మార్గాలు పేద ప్రత్యామ్నాయం.
సగం పూర్తయిన సంస్కరణను గమనించండి: స్పోక్ A కేంద్రం ద్వారా స్పోక్ B కు మార్గం చేస్తుంది, కేంద్రం రెండు వైపులా మార్గం చేస్తుంది, కానీ కేంద్ర ఫైర్వాల్ A నుండి కొత్త కనెక్షన్లను అనుమతిస్తుంది, B నుండి కాదు. మొదటి దిశ పరీక్షలో బాగుంటుంది, రెండోది వేలాడుతుంది; ఇది రూటింగ్ లోపంలా కనిపిస్తుంది, కానీ కాదు.
ముందు వైఫల్యాన్ని రూపొందించి, తర్వాత సాధారణ మార్గాన్ని
ఒకే కేంద్రం అంటే పంచుకున్న ఆధారం మరియు ట్రాన్సిట్ అడ్డంకి, రిడండెన్సీలోనే కేంద్ర డిజైన్లు సాధారణంగా తప్పుతాయి. రెండు కేంద్రాలు అంటే ప్రతి స్పోక్ రెండు టన్నెల్లను ఉంచుకోవాలి, తిరిగి వచ్చే మార్గం బయలుదేరే దానితో ఏకీభవించాలి; ఏకీభవించనప్పుడు స్థితి తెలిసిన ఫైర్వాల్ ప్రతిస్పందనలను రాలుస్తుంది, లక్షణం: తెరిచి ఆపై చనిపోయే కనెక్షన్. పెద్ద అమరికలు స్థిర ప్రిఫిక్స్లకు బదులు టన్నెల్లపై రౌటింగ్ ప్రోటోకాల్తో దీన్ని పరిష్కరిస్తాయి; ఇది ఎక్కువ యంత్రాంగం, కానీ ఊహను తొలగిస్తుంది. మీరు ఏది ఎంచుకున్నా తిరిగి వచ్చే మార్గాన్ని బయలుదేరే మార్గం పక్కనే రాయండి, ఎందుకంటే ఎవరూ పరీక్షించని సగం తిరిగి వచ్చే సగమే.
మెష్ ఆ ప్రమాదాన్ని పంచుతుంది: ఒక సైట్ లింక్ పడిపోతే మిగతావి ఒంటరిగా మారవు. మార్గ ఎంపిక మిమ్మల్ని ఆశ్చర్యపరిచే చోట్లను కూడా అది గుణిస్తుంది, అనువర్తన సెషన్లు ఇంకా సహాయం లేకుండా మార్గ మార్పును దాటి జీవించవు.
ఏ డిజైనూ ఒక TCP సెషన్ను ఫెయిల్ఓవర్ అంతటా తనంతట తాను సజీవంగా ఉంచదు. అనువర్తనం తిరిగి కనెక్ట్ కాలేకపోతే, టోపాలజీ మీ సమస్య కాదు.
మార్పు వ్యయంతో ఎంచుకోండి, తర్వాత మార్గాలను ధృవీకరించండి
కేంద్రంతో ప్రారంభించండి, ఎందుకంటే తప్పు అయితే నష్టం తక్కువ, ట్రాఫిక్ సమర్థించే జంటలకు నేరుగా టన్నెల్లు జోడించండి. ఆ హైబ్రిడ్ నిర్ణయించడంలో విఫలం కాదు; ఒక సంవత్సరంలో ఎక్కువ సంస్థలు చేరుకునే డిజైన్ అదే. ముఖ్యమైనది ఏమిటంటే ప్రతి నేరుగా లింక్కు చెప్పబడిన కారణం మరియు ఒక బాధ్యుడు ఉండాలి.
తర్వాత ఒకటి కాదు, రెండు రేఖాచిత్రాలను ధృవీకరించండి. సాధారణ మార్గం కోసం, ప్రతి సైట్ నుండి ప్రతి సేవా ప్రిఫిక్స్కు traceroute నడిపి హాప్లు రేఖాచిత్రంతో సరిపోతాయో నిర్ధారించండి. వైఫల్య మార్గం కోసం, ఒక టన్నెల్ను ఆపి మళ్లీ చేయండి, ఎందుకంటే అన్నీ పని చేస్తున్నప్పుడు మాత్రమే పని చేసే మార్గం రూపొందించబడలేదు, కాన్ఫిగర్ చేయబడింది మాత్రమే.
రెండు రేఖాచిత్రాలను ప్రాప్యత మాత్రికతో ఉంచండి, సైట్ జోడించినప్పుడు వాటిని మళ్లీ చూడండి; మీరు నిర్వహిస్తున్న ఖర్చు తదుపరి మార్పు ఖర్చే, ప్రస్తుత చిత్రం అందం కాదు.