కేటాయించిన వర్చువల్ IPలో IKEv2 క్లయింట్ను చేరుకోవడం
గేట్వే నుండి IKEv2 క్లయింట్ వైపు ప్రారంభమయ్యే అభ్యర్థనకు సరిపోలే ఎంపికకారు, సరైన స్థానిక మూలం మరియు చేరుకోగల చిరునామాలో వినేవాడు అవసరం. మూడింటినీ తనిఖీ చేయండి.
IKEv2 ద్వారా తనతో అనుసంధానమైన ల్యాప్టాప్కు గేట్వే కనెక్షన్ను ప్రారంభించాలి మరియు ఆ క్లయింట్కు కేటాయించిన వర్చువల్ చిరునామాను ఉపయోగించాలి. సొరంగం సక్రియంగా ఉంది, క్లయింట్ గేట్వే వెనుక ఉన్న ప్రతిదాన్ని చేరుకుంటుంది, కానీ వ్యతిరేక దిశ ఇప్పటికీ విఫలమవుతుంది. ఈ అసమానత సాధారణం: సంప్రదింపు చేసిన విధానం ఏ చిరునామాలు మాట్లాడగలవో వివరిస్తుంది, ఏ వైపు ప్రారంభించగలదో కాదు. గేట్వే ప్రారంభించిన అభ్యర్థన పనిచేయడానికి మూడు విషయాలు సరిపోలాలి.
సొరంగం మూల చిరునామాన్ని సరిచేయదు
CHILD SA ట్రాఫిక్ ఎంపికకారుల జతను కవర్ చేస్తుంది, ప్రతి వైపుకు ఒకటి, మరియు ఆ జత యొక్క రెండు దిశల్లోనూ ట్రాఫిక్ను అనుమతిస్తుంది. ఏ పీర్ IKE మార్పిడిని మొదట తెరిచిందో దాని గురించి ఏమీ చెప్పదు. మొదట సొరంగం కోసం విన్న గేట్వే ఇప్పటికీ మొదటి అప్లికేషన్ ప్యాకెట్ను పంపగలదు, ఎంచుకున్న మూలం మరియు గమ్యం ఇన్స్టాల్ చేసిన ఎంపికకారుల్లో ఉంటే. అభ్యర్థన తప్పు ఇంటర్ఫేస్ నుండి బయటకు వెళ్ళినప్పుడు, అది సొరంగానికి అర్హత కలిగినది కాదు.
క్లయింట్ వైపు రూటింగ్ అవసరం మరియు సరిపోదు. మీరు నిజంగా ఉపయోగించిన మూలాన్ని విధానం అంగీకరించాలి.
ఇన్స్టాల్ చేసిన విధానాన్ని చదవండి, కాన్ఫిగ్ ఫైల్ కాదు
సక్రియ అనుబంధం మరియు దాని ఎంపికకారుల నుండి ప్రారంభించండి, ఎందుకంటే క్రియాశీల కేటాయింపు కర్నెల్లో ఇన్స్టాల్ చేసినదాన్ని మారుస్తుంది.
ipsec statusall
ip xfrm policyస్థితి అవుట్పుట్ కనెక్షన్, కేటాయించిన వర్చువల్ చిరునామా మరియు ఆ పీర్కు ప్రస్తుతం వర్తించే ఎంపికకారులను పేర్కొంటుంది. విధానం డంప్ అదే ఎంపికకారులను కర్నెల్ స్థితిగా చూపిస్తుంది, ప్యాకెట్ ఎంపిక నిజంగా దానినే సంప్రదిస్తుంది. గేట్వే వైపు ఎంపికకారును మీ అప్లికేషన్ ఉపయోగించే మూలంతో పోల్చండి, ఎందుకంటే అసమానత వైఫల్యాన్ని వెంటనే వివరిస్తుంది. క్లయింట్ ప్రస్తుత చిరునామాను చదవండి, గత సెషన్ది కాదు, ఎందుకంటే మళ్లీ కేటాయించిన VIP పాత విధానాన్ని చెల్లనిదిగా చేస్తుంది.
క్లయింట్ ప్యాకెట్ వచ్చే చోటే వినాలి
సేవ లూప్బ్యాక్కు మాత్రమే బంధితమైతే పరిపూర్ణ విధానం కూడా మూసిన పోర్టుకు చేరుతుంది. వినేవాడు కేటాయించిన చిరునామాలో లేదా స్థానిక వైల్డ్కార్డ్ చిరునామాలో ఉండాలి.
ss -ltnp 'sport = :9090'
iptables -S INPUTసాకెట్ జాబితా పోర్టు వర్చువల్ చిరునామాకు బంధితమైందో లేదో చూపిస్తుంది, ఫైర్వాల్ నియమాలు రక్షిత మూలం నుండి కొత్త కనెక్షన్లు అంగీకరించబడుతున్నాయో లేదో చూపిస్తాయి. ఇప్పటికే ఏర్పాటైన కనెక్షన్ల కోసం రాసిన నియమం గేట్వే ప్రారంభించే కనెక్షన్ను అనుమతించదు. సేవ యొక్క స్వంత ప్రామాణీకరణను ఉంచండి, ఎందుకంటే సొరంగం ద్వారా రావడం ప్యాకెట్ ఏ నెట్వర్క్ నుండి వచ్చిందో మాత్రమే నిర్ధారిస్తుంది. స్వంత NAT వెనుక ఉన్న క్లయింట్కు ఇప్పటికీ లోపలికి వచ్చే పోర్టు ఫార్వార్డింగ్ అవసరం లేదు, ఎందుకంటే ఈ అభ్యర్థనలు ఉన్న సొరంగం లోపలే ప్రయాణిస్తాయి.
కొత్త దిశను విడిగా పరీక్షించండి
క్లయింట్ నుండి సర్వర్కు విజయవంతమైన అభ్యర్థన ఈ మార్గాన్ని ఎప్పుడూ ఉపయోగించదు. గేట్వే నుండి అభ్యర్థనను సృష్టించి రెండు చివరలను గమనించండి.
ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090మార్గ శోధన గేట్వే ఏ మూలాన్ని మరియు ఇంటర్ఫేస్ను ఉపయోగిస్తుందో సమాధానమిస్తుంది, విధానం అంగీకరించాల్సిన విలువ అదే. క్యాప్చర్ అభ్యర్థన పబ్లిక్ ఇంటర్ఫేస్లో సాధారణ TCPగా కాకుండా ESP లోపల బయటకు వెళ్తున్నట్లు చూపాలి. క్లయింట్లో, చేరిక మరియు సేవ సమాధానం ఇచ్చిందో లేదో నిర్ధారించడానికి డీక్రిప్ట్ చేసిన ట్రాఫిక్ను క్యాప్చర్ చేయండి. అభ్యర్థన వైర్లో ESP లేకుండా మాయమైతే, క్లయింట్ ఫైర్వాల్కు ముందు మూల చిరునామాపై అనుమానించండి.
కీ మార్పు లేదా తిరిగి కనెక్ట్ అయిన తర్వాత పరీక్షను పునరావృతం చేయండి, ఎందుకంటే VIP మారవచ్చు. తదుపరి సెషన్ వరకు మాత్రమే పనిచేసే మార్గం పనిచేసే మార్గం కాదు.