రూట్ ఆధారిత vs విధాన ఆధారిత సైట్-టు-సైట్ VPN: ఏమి భిన్నంగా ఉంటుంది
విధాన ఆధారిత IPsec ఎంపికద్వారా ట్రాఫిక్ను ఎంచుకుంటుంది; రూట్ ఆధారితం దాన్ని టన్నెల్ ఇంటర్ఫేస్ ద్వారా పంపుతుంది. రెండింటికీ ఇంకా ఫైర్వాల్ నియమాలు మరియు తిరిగి వచ్చే మార్గం అవసరం.
రెండు నిర్మాణాలు ఒకే ట్రాఫిక్ను ఒకే IPsec యంత్రంతో రక్షిస్తాయి, మరియు ఏ ప్యాకెట్ టన్నెల్లోకి ప్రవేశిస్తుందో ఏది నిర్ణయిస్తుందనే విషయంలో అవి భిన్నంగా ఉంటాయి. విధాన ఆధారిత కనెక్షన్లో చర్చించిన ట్రాఫిక్ ఎంపికద్వారాలు ఆ పని చేస్తాయి; రూట్ ఆధారిత కనెక్షన్లో టన్నెల్ ఇంటర్ఫేస్ వైపు చూపే మార్గం ఆ పని చేస్తుంది. రెండింటినీ కలిపేయడం వల్ల టన్నెల్ తాను స్థాపించబడినట్లు నివేదిస్తుంది కానీ అప్లికేషన్ ఏదీ చేరుకోలేదు అనే పరిచిత సపోర్ట్ థ్రెడ్ ఏర్పడుతుంది. మీరు నెట్వర్క్ను జోడించినప్పుడు, రూటింగ్ ప్రోటోకాల్ను నడిపినప్పుడు, లేదా తప్పు నిష్క్రమణ ద్వారా నిశ్శబ్దంగా బయటకు వెళ్లే మార్గాన్ని డీబగ్ చేసినప్పుడు ఈ భేదం చాలా ముఖ్యం.
టన్నెల్లోకి ఏమి ప్రవేశిస్తుందో నిర్ణయించే రెండు మార్గాలు
విధాన ఆధారిత VPN మూలం మరియు గమ్యం ప్రిఫిక్స్లతో సరిపోయే భద్రతా విధానాన్ని నిర్మించి, ఆపై సరిపోయేదాన్ని గుప్తీకరిస్తుంది. భాగస్వామి అనుకూల ఎంపికద్వారాలను చర్చించుకోవాలి, కాబట్టి ప్రభావవంత పరిధి చివరికి రెండు వైపులా ప్రతిపాదించిన దాని ఖండనగా మారుతుంది. ఆ ఖండన వెలుపల ఏదీ రక్షించబడదు, రూటింగ్ పట్టిక ఏమి చెప్పినా.
రూట్ ఆధారిత VPN టన్నెల్ను సూచించే ఇంటర్ఫేస్ను సృష్టించి రూటింగ్ పట్టిక దానిలోకి ట్రాఫిక్ పంపడానికి అనుమతిస్తుంది. IKE డీమన్ ఇంకా స్థితి మరియు ప్రతి ఇంటర్ఫేస్ విధానాన్ని ఇన్స్టాల్ చేస్తుంది, మరియు మార్గాలు గుప్తీకరణను భర్తీ చేశాయని నిర్ణయించుకున్నప్పుడు ప్రజలు దాటవేసే వివరం అదే. రెండు నిర్మాణాలు IPsecతో గుప్తీకరిస్తాయి; ఎంపిక యంత్రాంగం మాత్రమే భిన్నం.
క్రింది పోలికను స్కోర్కార్డుగా కాకుండా వైఫల్య సంకేతాల సమూహంగా చదవండి, ఎందుకంటే ఏ నిలువు వరుసా తనంతట తాను గెలవదు.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
విధాన ఆధారితం: ఎంపికద్వారమే ఒప్పందం
ఎంపికద్వారాలు చర్చించబడతాయి, కేవలం కాన్ఫిగర్ చేయబడవు. ఒక వైపు 10.10.0.0/16 మరియు మరో వైపు 10.10.1.0/24 ప్రతిపాదించండి, అప్పుడు సంఘం చర్చ ఆగిన దాన్ని కవర్ చేస్తుంది, మిగిలిన ప్రతి హోస్ట్ బయటే ఉంటుంది.
కాన్ఫిగరేషన్ ఫైల్కు బదులుగా ఇన్స్టాల్ చేసిన స్థితిని చదవండి. Linux భాగస్వామిపై కెర్నల్ సొంత పట్టికలే ప్రాథమిక సత్యం, అవి చర్చ నుండి ఏమి మిగిలిందో చూపుతాయి. సరైన ప్రిఫిక్స్లను పేర్కొని సరిపోయే స్థితి లేని విధానం అంటే సంఘం ఎప్పుడూ లేచలేదు. తప్పు ప్రిఫిక్స్ కోసం విధానంతో జత చేయబడిన స్థితి వ్యతిరేక సమస్య, అది ఆరోగ్యకరంగా కనిపించే టన్నెల్ను సృష్టిస్తుంది కానీ ఒక సబ్నెట్ ఏదీ చేరుకోలేదు.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasమీరు రక్షిస్తున్నాయని అనుకునే ప్రిఫిక్స్లతో రెండు అవుట్పుట్లను పోల్చండి. ఆ ఒకే పోలిక పని చేసే టన్నెల్ మరియు చేరుకోలేని సర్వర్ గురించి చాలా నివేదికలను పరిష్కరిస్తుంది. ఏ భాగస్వామిని మార్చాలో కూడా అది చూపుతుంది, ఎందుకంటే అసమానత సాధారణంగా ఒక దిశలో మాత్రమే కనిపిస్తుంది.
రూట్ ఆధారితం: ఇంటర్ఫేసే ఒప్పందం
XFRM ఇంటర్ఫేస్ టన్నెల్కు పేరు మరియు గుర్తింపు ఇస్తుంది, రూటింగ్ పట్టిక అలా చెప్పడం వల్ల ట్రాఫిక్ దాన్ని చేరుతుంది. అనేక దూర ప్రిఫిక్స్లు అప్పుడు ఎంపికద్వార సమస్యగా కాకుండా రూటింగ్ సమస్యగా మారుతాయి, రూటింగ్ ప్రోటోకాల్ వాటిని ప్రకటించగలదు. అదే నిజమైన లాభం, గుప్తీకరణ కాదు.
ఇంటర్ఫేస్ విధానం అవసరాన్ని తొలగించదు. డీమన్ ఇంటర్ఫేస్ గుర్తింపుతో ముడిపడిన నియమాలను ప్రతి ఇంటర్ఫేస్కు ఇన్స్టాల్ చేస్తుంది, కాబట్టి తప్పు ఇంటర్ఫేస్కు వచ్చే ప్యాకెట్ ఇప్పటికీ విఫలమవుతుంది. భాగస్వామి అంగీకరించని మూల చిరునామా కూడా పరిపూర్ణ మార్గం ఉన్నా విఫలమవుతుంది. రూట్ ఆధారితం అంటే ప్రవేశాన్ని మార్గం నిర్ణయిస్తుంది, విధానం మాయమైంది అని కాదు.
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10మార్గం స్థిరపడిన తర్వాత ఇంటర్ఫేస్ కౌంటర్లను గమనించండి. మార్గం ఉంది కానీ కౌంటర్లు సున్నాలో ఉంటే టన్నెల్లోకి ఏదీ సరిపోల్చబడటం లేదని అర్థం, ఇది సాధారణంగా లేని మార్గం కంటే లేని స్థితిని సూచిస్తుంది.
ఈ రెండు నిర్మాణాలు నిజంగా ఎక్కడ విడిపోతాయి
నెట్వర్క్ను జోడించడం ఏ మోడల్ మీకు సరిపోతుందో పరీక్షించడానికి అత్యంత శుభ్రమైన పరీక్ష. రూట్ ఆధారిత నిర్మాణం ఒక మార్గాన్ని జోడించి గరిష్ఠంగా ఒకసారి ఎంపికద్వారాన్ని విస్తరిస్తుంది, విధాన ఆధారిత నిర్మాణం రెండు భాగస్వాములపై ప్రిఫిక్స్ జతలను సవరించి మళ్లీ చర్చిస్తుంది. రెండు స్థిరమైన సబ్నెట్లు ఆ సవరణను తుచ్ఛంగా చేస్తాయి, ఇరవై అది ప్రాజెక్టుగా మారుస్తాయి.
ఏ మోడలూ ఫైర్వాల్ను భర్తీ చేయదు, పోలికలు సాధారణంగా ఈ బిందువుకు ముందే ఆగిపోతాయి. విశాలమైన ఎంపికద్వారం లేదా విశాలమైన మార్గం ఏది గుప్తీకరించబడుతుందో నిర్ణయిస్తుంది, ఏది అనుమతించబడుతుందో కాదు.
MTU ప్రవర్తన కూడా ఆచరణలో భిన్నం. ఎన్క్యాప్సులేషన్ ఉపయోగకరమైన పేలోడ్ను తగ్గిస్తుంది, రూట్ ఆధారిత ఇంటర్ఫేస్ తన సొంత MTUని మోస్తుంది, కాబట్టి రెండు గేట్వేలపై MSS క్ల్యాంప్ చేయడం చిన్న ప్రతిస్పందనలు వచ్చి పెద్దవి మాయమయ్యే నల్ల రంధ్ర లక్షణాన్ని నివారిస్తుంది. విధాన ఆధారిత టన్నెల్లు మరో వైపు నుండి అదే గోడను ఎదుర్కొంటాయి, ఎందుకంటే ఎంపికద్వారం ప్యాకెట్ పరిమాణం గురించి ఏమీ చెప్పదు. భాగస్వామిని నిందించే బదులు క్ల్యాంప్ను ఉద్దేశపూర్వకంగా సెట్ చేయండి.
తిరిగి వచ్చే మార్గాన్ని కోల్పోకుండా వలస
ఏదైనా మార్చే ముందు ఉన్న ప్రిఫిక్స్ జతలను నమోదు చేయండి, తర్వాత ఒక అప్లికేషన్ మార్గాన్ని తరలించి దాన్ని మొదటి నుండి చివరి వరకు గమనించండి. స్థాపించబడే టన్నెల్ ఫార్వార్డ్ చేసే టన్నెల్ కాదు, భేదం ప్రతిస్పందన దిశలో కనిపిస్తుంది.
భాగస్వాములు కనెక్ట్ అవుతారు కానీ LAN హోస్ట్లు కావు అయినప్పుడు, తిరిగి వచ్చే మార్గం మరియు దూర హోస్ట్ ఉపయోగించే మూల చిరునామాను పరిశీలించండి. రెండు ఇంటర్ఫేస్లు ఉన్న హోస్ట్ తప్పు దాని నుండి ప్రతిస్పందించవచ్చు, ఏ ఎంపికద్వార మార్పూ దాన్ని సరిచేయదు. అల్గారిథమ్లను సవరించే ముందు రెండు చివరల్లో ట్రాఫిక్ను సంగ్రహించండి.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsపని చేస్తున్నప్పుడు టన్నెల్పై ఆధారపడని నిర్వహణ మార్గాన్ని ఉంచండి. మీరు డీబగ్ చేస్తున్న కనెక్షన్పై గేట్వే సొంత యాక్సెస్ ఎక్కకపోతే వెనక్కి తిరగడం సులభం.