ఒకే WAN ఇంటర్ఫేస్ సైట్-టు-సైట్ మరియు రిమోట్ VPN రెండింటినీ సేవించగలదా?

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

శీఘ్ర వివేక పరీక్ష: రౌటర్ను తాకే ముందు రెండు ప్రవేశ రికార్డులను రాయడానికి ప్రయత్నించండి. ఒకే సరిపోలిక షరతు రెండింటినీ కవర్ చేయాల్సి ఉంటే, విధానం ఇప్పటికే అస్పష్టంగా ఉంది, మరియు మొదటి లక్షణం రౌటింగ్ లేదా ఫైర్వాల్ వైఫల్యంలా కనిపిస్తుంది, వాస్తవానికి అది గుర్తింపు వైఫల్యం.

ఏదైనా కాన్ఫిగరేషన్కు ముందు రెండు రికార్డులు

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

తిరుగుడు రికార్డు మరింత విస్తృతమైనది మరియు వ్యక్తిగతమైనది. ఇది క్లయింట్ ప్రోటోకాల్ మరియు పోర్టు, వినియోగదారు లేదా పరికరం ఎలా ప్రామాణీకరిస్తుంది, కనెక్ట్ అయ్యేటప్పుడు ఇచ్చే చిరునామా పూల్, ఆ పూల్ చేరగల వనరులు, విభజిత టన్నెల్ ప్రిఫిక్స్లు, క్లయింట్కు నెట్టే DNS సర్వర్లు, మరియు ఏదైనా రెండవ అంశాన్ని జాబితా చేస్తుంది. ప్రతి క్షేత్రం ఒక గేట్వే గురించి కాకుండా తెలియని సంఖ్యలో వినియోగదారుల గురించిన ప్రశ్నకు సమాధానం ఇస్తుంది.

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

పీర్ సరిపోలిక మరియు ప్రామాణీకరణ ఎక్కడ విడిపోతాయి

IOS XE లో IKEv2 ప్రొఫైల్ చర్చించలేని పరామితులను మరియు పీర్ను ఎంచుకోవడానికి ఉపయోగించే షరతులను మోస్తుంది. అంటే శాఖ వైపు మరియు తిరుగుడు వైపు ప్రతిదీ తన స్వంత ప్రొఫైల్ను కలిగి ఉండాలి, అవి ఒకే ఇంటర్ఫేస్పై ముగిసినా మరియు ఒకే క్రిప్టో PKI పంచుకున్నా. Cisco తన IOS XE 17 కోసం IKEv2 కాన్ఫిగరేషన్ గైడ్లో.

శాఖ ప్రొఫైల్ సాధారణంగా ఒక ఇరుకైన గుర్తింపుతో సరిపోలుతుంది: దూర చిరునామా, FQDN, లేదా ధృవపత్రం విషయం. match identity remote address 198.51.100.10 255.255.255.255 వంటిది ఒక పీర్ను పిన్ చేస్తుంది, మరియు ప్రతి సైట్కు నిల్వ చేసిన కీతో authentication remote pre-share సరిపోతుంది. పీర్ జాబితా అనుమతించినంత నిర్దిష్టంగా సరిపోలికను ఉంచండి, ఎందుకంటే ఎంపిక క్రమంలో పైన ఉన్న అతివ్యాప్త వైల్డ్కార్డ్ శాఖ ట్రాఫిక్ను తప్పు ప్రొఫైల్లోకి లాగగలదు.

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

ఫార్వర్డింగ్ మరియు అనువాదానికి కూడా అదే విభజన కావాలి

ప్రవేశం మరియు చేరుకోవడం వేర్వేరు సమస్యలు. విజయవంతమైన IKE మరియు IPsec మార్పిడి రెండు పక్షాలు కీలపై అంగీకరిస్తున్నాయని నిరూపిస్తుంది; అది క్లయింట్ పొందిన పూల్కు మార్గాన్ని సృష్టించదు. అందువల్ల రిమోట్ యాక్సెస్ పూల్స్కు తిరిగి వచ్చే మార్గం కావాలి: టన్నెల్ ఇంటర్ఫేస్ వైపు స్థిర మార్గం లేదా పూల్ సారాంశాన్ని చొప్పించే రౌటింగ్ ప్రోటోకాల్. శాఖ ప్రిఫిక్స్లు సాధారణంగా సైట్లోని మిగిలిన భాగానికి సేవ చేసే అదే రౌటింగ్ ప్రక్రియ ద్వారా వస్తాయి.

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

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

క్రాస్ అయిన విధానాన్ని బయటపెట్టే అంగీకార సందర్భాలు

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

తర్వాత కాన్ఫిగరేషన్ కాదు, డేటా ప్లేన్ నిర్ధారించండి. show crypto ikev2 sa మరియు show crypto ipsec sa ఏ ప్రొఫైల్ మరియు ఏ సెలెక్టర్లు ప్రతి ప్రవాహాన్ని మోశాయో చెబుతాయి, show ip nat translations మరియు టన్నెల్ కౌంటర్లు తిరిగి వచ్చే మార్గం మరియు మినహాయింపు నిజంగా సరిపోలాయా అని చూపుతాయి. టన్నెల్ ఇంటర్ఫేస్పై tracer లేదా ప్యాకెట్ క్యాప్చర్ లూప్ను మూస్తుంది.

ప్రతి ఫలితం పక్కన గమనించిన గుర్తింపు, పూల్ చిరునామా మరియు ఎంచుకున్న విధానాన్ని రాయండి. ప్రతి సందర్భం సరిగ్గా ఒక రికార్డుతో సరిపోలి, ఏ సందర్భానికీ ఉత్తీర్ణత కోసం తాత్కాలిక మినహాయింపు అవసరం లేనప్పుడు పరుగు పూర్తవుతుంది.