IPsec లోపల IPsec: బయటి సొరంగం ఏ చిరునామాలను మోసుకెళ్లాలి

రెండు పొరలు వేర్వేరు యంత్రాలలో ముగిసినప్పుడు నెస్టెడ్ IPsec గురించి ఆలోచించడం సులభం. నాలుగు గేట్వేలు, రెండు సొరంగాలు, మరియు రూపకల్పన పనిచేస్తుందో లేదో నిర్ణయించే ఒక ప్రశ్న: లోపలి సొరంగం ప్యాకెట్తో పూర్తయిన తర్వాత బయటి సొరంగం నిజంగా ఏమి చూస్తుంది? దానికి సమాధానం చెప్పండి, సెలెక్టర్లు, మార్గాలు మరియు సమస్య పరిష్కార క్రమం తమంతట తామే వస్తాయి. తప్పు చేస్తే సాంకేతికంగా నడుస్తున్న సొరంగాన్ని డీబగ్ చేస్తూ ఒక రోజు గడుపుతారు.

నాలుగు గేట్వేల నమూనా

బయటి గేట్వేలు A మరియు B రెండు సైట్ల మధ్య మొదటి సొరంగాన్ని నిర్మిస్తాయి. A వెనుక ట్రాన్సిట్ చిరునామా 10.60.0.2 కలిగిన లోపలి గేట్వే C, B వెనుక ట్రాన్సిట్ చిరునామా 10.70.0.2 కలిగిన లోపలి గేట్వే D ఉన్నాయి. యాప్లికేషన్ నెట్వర్క్లు C మరియు D వెనుక ఉంటాయి, మరియు ఉదాహరణలోని ప్రతి చిరునామా ఉద్దేశపూర్వకంగా అతిపాతం చెందదు.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

ప్రతి పొర తన స్వంత రక్షణను మాత్రమే తొలగిస్తుంది

C, D కోసం యాప్లికేషన్ ప్యాకెట్ను ఎన్క్రిప్ట్ చేస్తుంది. ఫలితం C నుండి Dకి చిరునామా చేయబడుతుంది, అదే Aను చేరుతుంది. తర్వాత జరిగేదంతా ఆ పునర్లేఖనంపై ఆధారపడి ఉంటుంది.

A దాన్ని B కోసం మళ్లీ ఎన్క్రిప్ట్ చేస్తుంది. B బయటి పొరను డీక్రిప్ట్ చేసి, C నుండి Dకి వెళ్లే ప్యాకెట్ను చూసి, దాన్ని ఇంకా ఎన్క్రిప్ట్ చేయబడిన స్థితిలోనే ముందుకు పంపుతుంది. D లోపలి రక్షణను తొలగించి యాప్లికేషన్ ప్యాకెట్ను అందిస్తుంది.

కాబట్టి A మరియు B లోపలి ముగింపు బిందువులను మరియు వాటి మెటాడేటాను చూస్తాయి, కానీ యాప్లికేషన్ పేలోడ్ను డీక్రిప్ట్ చేసే పక్షాలు అవి కావు. ఇది రూపకల్పన యొక్క నిజమైన లక్షణం, C, D లేదా యాప్లికేషన్ హోస్ట్లు విశ్వసనీయమని చెప్పడం కాదు.

బయటి సెలెక్టర్లు లోపలి గేట్వేలను పేర్కొంటాయి

ఇక్కడే ఇటువంటి నిర్మాణాలలో చాలావరకు విఫలమవుతాయి. విధాన ఆధారిత బయటి సొరంగం కోసం, మీరు చర్చించే సెలెక్టర్లు A మరియు B నిజంగా నిర్వహించే చిరునామాలను కలిగి ఉండాలి: 10.60.0.2/32 మరియు 10.70.0.2/32, సరైన స్థానిక మరియు దూర క్రమంలో.

తుది యాప్లికేషన్ సబ్నెట్లను బయటి సెలెక్టర్లలో పెట్టడం పనిచేయదు, ఎందుకంటే ప్యాకెట్ Aకు చేరేసరికి లోపలి ఎన్క్యాప్సులేషన్ A రక్షించాల్సిన దాన్ని ఇప్పటికే తిరిగి రాసేసి ఉంటుంది. అప్పుడు బయటి విధానం ఏదీ సరిపోలదు, సొరంగం డేటా మోయకుండానే పైకి వస్తుంది.

బయటి అనుమతిని UDP 500కు కుదించవద్దు. లోపలి కనెక్షన్కు దాని స్వంత డేటా మార్గం ఉంది, అది చర్చించిన దాని ప్రకారం ESP లేదా UDP ఎన్క్యాప్సులేషన్ ఉపయోగిస్తుంది, బయటి విధానం ఆ ప్రోటోకాల్ను అనుమతించాలి.

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

ఫార్వర్డింగ్ మరియు పునరావృత వల

సెలెక్టర్లు మార్గనిర్దేశనాన్ని భర్తీ చేయవు. A మరియు B C మరియు D మధ్య రెండు దిశల్లోనూ ట్రాఫిక్ను ఫార్వర్డ్ చేయాలి, అంటే IP ఫార్వర్డింగ్ ప్రారంభమైంది, సొరంగం వైపు చూపే మార్గాలు మరియు అవతలి వైపు ఉన్న తిరిగి వెళ్లే మార్గం.

బయటి సొరంగం XFRM ఇంటర్ఫేస్లను ఉపయోగిస్తే, మార్గాలు ఇంటర్ఫేస్ను ఎంచుకుంటాయి, చర్చించిన విధానాలు అది ఏమి మోస్తుందో ఇంకా పరిమితం చేస్తాయి. ఇంటర్ఫేస్ రక్షిత పరిధిని విస్తరించదు; కర్నెల్ ప్యాకెట్ను ఎలా తీసుకుంటుందో మాత్రమే మారుస్తుంది.

వల పునరావృతం. B యొక్క బయటి ముగింపు బిందువుకు A యొక్క మార్గం A నిర్మిస్తున్న సొరంగాన్ని కాదు, కింది నెట్వర్క్ను అనుసరించాలి, లేకపోతే ఎన్క్యాప్సులేషన్ తనలో తాను ప్రయాణించడానికి ప్రయత్నిస్తుంది, కనెక్షన్ ఎప్పటికీ పూర్తికాదు.

పొరలను జోడించే ముందు అనువాదాన్ని పరిశీలించండి

మరేదైనా ట్యూన్ చేయడానికి ముందు A మరియు Bలోని ఏదైనా మూల NATను చూడండి. IPsec విధానం వర్తించే ముందు C చిరునామాను తిరిగి రాసే నియమం అంగీకరించిన సెలెక్టర్లను బద్దలు కొట్టవచ్చు, అలాగే D అవతలి వైపు ఏమి స్వీకరిస్తుందో కూడా మార్చవచ్చు.

రెండు పొరలు ఉన్నందున విస్తృత మాస్కరేడింగ్ మరింత సురక్షితం కాదు. ఇది దూరపు వైపు ఏ చిరునామాను చూస్తుందో దాచుతుంది, సొరంగం నడుస్తూ యాప్ నడవనప్పుడు సరిగ్గా ఆ సమాచారమే కావాలి.

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

fail-closed నిరూపించి MTU తనిఖీ చేయండి

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

మూడు స్థితులను పరీక్షించండి: బయటి సొరంగం కింద, లోపలి సొరంగం కింద, మరియు రెండూ తిరిగి వచ్చిన తర్వాత కోలుకోవడం. ప్రతి గేట్వేలో విధాన కౌంటర్లను ఉపయోగించండి, ఎందుకంటే స్థాపించిన రెండు IKE సెషన్లు నియంత్రణ తల చర్చలు విజయవంతమయ్యాయని మాత్రమే నిరూపిస్తాయి.

రెండు ఎన్క్యాప్సులేషన్లకూ బడ్జెట్ పెట్టండి. పనిచేసే IKE చిన్న ప్యాకెట్ల ఫలితం, రెండు హెడర్లు జోడించిన తర్వాత పూర్తి పరిమాణ యాప్లికేషన్ ప్యాకెట్లు ఇంకా విఫలమవవచ్చు; సంఖ్యలు కలుస్తాయని ఊహించే బదులు నిజమైన మార్గంలో తెలిసిన పేలోడ్ పరిమాణంతో పరీక్షించండి. గణితం సులభం, మార్గం కాదు.