strongSwan నుండి AWS Site-to-Site వరకు: Child SA ఏమీ ఎందుకు ఎంచుకోదు

IKE సొరంగం పనిచేస్తున్నప్పటికీ చైల్డ్ అసోసియేషన్ మీ సబ్నెట్లను మినహాయించవచ్చు. మొదట AWS యొక్క లోకల్ మరియు రిమోట్ CIDR లను leftsubnet, rightsubnet తో పోల్చండి.

కన్సోల్ up చూపిస్తుంది, strongSwan స్థాపిత IKE అసోసియేషన్ను నివేదిస్తుంది, ప్యాకెట్లు ఇంకా రావట్లేదు. తర్వాత పోల్చవలసినది ముందుగా పంచుకున్న కీ కాదు, ప్రతి వైపు సొరంగం రక్షిస్తుందని నమ్మే ప్రిఫిక్స్ల జంట. క్రింది తనిఖీలను క్రమంగా చేయండి, ఎందుకంటే మొదటి రెండు సొరంగం మీ ట్రాఫిక్ను అసలు మోయగలదో లేదో నిర్ణయిస్తాయి.

AWS పేర్లను strongSwan పదాలకు అనువదించండి

AWS కనెక్షన్ను కస్టమర్ వైపు నుండి వివరిస్తుంది: కస్టమర్ గేట్వే చిరునామా మరియు లోకల్ CIDR మీవి, రిమోట్ CIDR VPC ది. strongSwan రెండు చివరలను left మరియు right అని పిలుస్తుంది, మీ ప్రిఫిక్స్ leftsubnet లో, VPC ప్రిఫిక్స్ rightsubnet లో ఉంటుంది. ఒక జంటను తిప్పితే తప్పు ట్రాఫిక్ను చర్చించి ఎంచుకునే సొరంగం ఏర్పడుతుంది.

AWS కనెక్షన్ కోసం సృష్టించే కాన్ఫిగరేషన్ను డౌన్లోడ్ చేసి, సొరంగ చిరునామాలు మరియు ప్రిఫిక్స్లతో సహా దాన్నే ఆ కనెక్షన్ సూచనగా తీసుకోండి. సృష్టించేటప్పుడు రెండు CIDR ఫీల్డ్లను ఖాళీగా వదిలితే సేవ ప్రతి వైపు 0.0.0.0/0 డిఫాల్ట్ను ఉపయోగిస్తుంది. ఇరుకైన ప్రిఫిక్స్తో కాన్ఫిగర్ చేసిన రౌటర్ అప్పుడు ఎప్పటికీ సరిపోలదు, కాబట్టి ఫీల్డ్లను నింపండి లేదా సెలెక్టర్ను ఉద్దేశపూర్వకంగా విస్తరించండి.

ఇక్కడి అసమానత రౌటింగ్ వైఫల్యంలా కనిపిస్తుంది, కానీ కాదు.

AWS నిజంగా చూసే చిరునామాను స్థిరపరచండి

NAT వెనుక ఉన్న రౌటర్ ఎదురు వైపు ఎప్పుడూ తెలియని ఇంటర్ఫేస్ నుండి IKE పంపవచ్చు. AWS లో నమోదైన గేట్వే చిరునామా AWS నెట్వర్క్లో చూసేదే ఉండాలి, రౌటర్ తన డిఫాల్ట్ మార్గాన్ని అనుసరించకుండా అదే లోకల్ చిరునామాకు స్థిరపరచాలి.

conn %default
    local_addrs = 203.0.113.10

strongSwan లో local_addrs IKE కోసం మూల చిరునామాన్ని ఎంచుకుంటుంది, పాత OpenSwan కాన్ఫిగరేషన్లు అదే భావనను left గా రాస్తాయి. దాన్ని పబ్లిక్ చిరునామా ఉన్న ఇంటర్ఫేస్ వైపు మళ్లించి, తర్వాత NAT పరికరంలోనే UDP 500 మరియు 4500 ఆ హోస్ట్కు చేరుతాయని నిర్ధారించండి, ఎందుకంటే మునుపటి రౌటర్ నుండి మిగిలిన నియమం వాటిని నిశ్శబ్దంగా పడేస్తుంది. సరైన సెలెక్టర్ జంట తప్పు మూల చిరునామాతో అయినా విఫలమవుతుంది, లాగ్ ప్రతిపాదనను నిందిస్తుంది. ఆ తప్పుదోవ పట్టించడమే మూల చిరునామాకు ప్రత్యేక తనిఖీ అవసరమని చెప్పే కారణం.

ఫార్వర్డింగ్ నియమాన్ని ఊహించకుండా నిర్ధారించండి, ఎందుకంటే మునుపటి రౌటర్కు సరైనదిగా ఉన్న నియమం తరచుగా మిగిలిపోతుంది.

దశ 1 మరియు దశ 2 లను విడివిడిగా నిర్వహించండి

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

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

వాక్యనిర్మాణం అమలుల మధ్య ప్రయాణించదు. OpenSwan లో పనిచేసే జంట, ఉదాహరణకు phase2alg=aes_gcm తో ike=aes256-sha1;modp1024, strongSwan esp= మరియు ike= రూపంలోకి అనువదించాలి, అల్గారిథమ్ పేర్లు భిన్నంగా ఉంటాయి. GCM ఎన్క్రిప్ట్ చేస్తూనే ప్రామాణీకరిస్తుంది కాబట్టి, SHA తో జోడించిన CBC సెట్ లాగా దానికి ప్రత్యేక సమగ్రతా రూపాంతరం అవసరం లేదు. ఒక డీమన్ నుండి మరొకదానికి అనువాదం లేకుండా అతికించిన దశ 2 పంక్తి సెలెక్టర్ అసమానతలా చదవబడే తిరస్కరణను సృష్టిస్తుంది.

సొరంగ సూచిక కాదు, చైల్డ్ అసోసియేషన్ తనిఖీ చేయండి

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

ipsec statusall

చైల్డ్ భద్రతా అసోసియేషన్ను కనుగొని దాని పక్కన ముద్రించిన ట్రాఫిక్ సెలెక్టర్లను చదవండి, తర్వాత వాటిని సృష్టించిన కాన్ఫిగరేషన్ ప్రిఫిక్స్లతో పోల్చండి.

లోకల్ ప్రిఫిక్స్ లోపలి హోస్ట్ నుండి VPC ప్రిఫిక్స్ లోపలి హోస్ట్కు పరీక్షించి, తిరుగు మార్గం మరియు AWS వైపు ఏదైనా భద్రతా సమూహం లేదా నెట్వర్క్ ACL తనిఖీ చేయండి. సరైన సెలెక్టర్లు ప్యాకెట్ తర్వాత పడేయబడకుండా రక్షించవు.

సెలెక్టర్లు సరిపోలిన తర్వాత కూడా విఫలమైతే

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

మరో ప్రతిపాదనను మార్చే ముందు ప్రతి వైపు ఒక లోపలికి వచ్చే మరియు ఒక బయటికి వెళ్లే ప్యాకెట్ను లాగ్ చేయండి.

టికెట్లో సెలెక్టర్లు, దశ 1 మరియు దశ 2 ప్రతిపాదనలు మరియు మూల చిరునామా నమోదు చేయండి. ఈ నాలుగు విలువలు కాల్ లేకుండా చాలా site-to-site వైఫల్యాలను వివరిస్తాయి.

సంబంధిత వ్యాసాలు