Check Point లేదా Nortel ఎదురుగా vpnc: అది ఎందుకు వేలాడుతుంది

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

ప్రొఫైల్‌లోని మరో ఫీల్డ్‌ను సవరించే ముందు ఉత్పత్తిని గుర్తించండి.

వైఫల్యం తప్పు ఆధారాల్లా కనిపిస్తుంది

vpnc UDP 500 కు IKE పంపడం ద్వారా ప్రారంభమవుతుంది మరియు NAT ట్రావర్సల్ అందించబడితే UDP 4500 కు కూడా. IPsec బదులు SSL ముగించే గేట్‌వే రెండింటికీ సమాధానం ఇవ్వదు, కాబట్టి క్లయింట్ మళ్లీ ప్రయత్నించి చివరికి సాధారణ లోపంతో వదిలేస్తుంది. అదే ఖాతా చిన్న సహాయక యాప్ లోడ్ చేసే బ్రౌజర్ పోర్టల్ ద్వారా పనిచేస్తే, సొరంగం SSL ఆధారితమని మరియు క్లయింట్ తప్పు ప్రశ్న అడుగుతోందని ఇది బలమైన సూచన.

ఇక్కడ విఫలమైన ప్రయత్నం వినియోగదారు ఖాతా గురించి ఏమీ చెప్పదు, ఎందుకంటే గేట్‌వేకు ఎప్పుడూ ఆధారాలు సమర్పించబడలేదు.

గేట్‌వే ఏ ప్రోటోకాల్ అందిస్తుందో తనిఖీ చేయండి

రెండు నిమిషాల పరిశోధన IPsec భాగస్వామిని SSL పోర్టల్ నుండి వేరు చేస్తుంది. క్లయింట్ ఉపయోగించే అదే నెట్‌వర్క్ నుండి వాటిని అమలు చేయండి, మరియు పత్రంలో ఏ పోర్టులు ఉన్నాయో కాదు, ఏ పోర్టులు సమాధానం ఇస్తాయో చదవండి. ఫలితాన్ని ఉంచండి, ఎందుకంటే అదే పోర్టులే గేట్‌వే యజమాని ఏ క్లయింట్‌కు మద్దతు ఇవ్వాలో నిర్ణయిస్తాయి. గేట్‌వే పక్కన ఉన్న హోస్ట్ నుండి కాదు, క్లయింట్ నెట్‌వర్క్ నుండి పరిశోధించండి.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

లాగిన్ పేజీకి మళ్లింపుతో తెరిచిన 443 మరియు 500, 4500 పై నిశ్శబ్దం SSL VPN వైపు సూచిస్తుంది. 443 పై అందించిన ప్రమాణపత్రంతో 500 మరియు 4500 తెరిచి ఉంటే వెబ్ ముందుభాగాన్ని కూడా నడిపే IPsec గేట్‌వేను సూచిస్తుంది, vpnc అందుకే నిర్మించబడింది.

Check Point యొక్క SSL Network Extender మరియు Nortel యొక్క Aventail క్లయింట్ రెండూ రెండవ వర్గంలో ఉన్నాయి, మరియు ఏదీ IKEv1 సమూహ రహస్యాన్ని అంగీకరించదు.

vpnc ప్రొఫైల్ ఏమి వ్యక్తపరచగలదు మరియు ఏమి కాదు

లోపల vpnc సమూహ ముందుగా పంచుకున్న కీకి వ్యతిరేకంగా IKEv1 నడుపుతుంది, తర్వాత XAuth ద్వారా వ్యక్తిగత వినియోగదారు ఆధారాలను పంపుతుంది. దాని కాన్ఫిగరేషన్ ఫైల్‌లోని ప్రతిదీ ఆ మార్పిడికి చెందుతుంది: గేట్‌వే, సమూహ పేరు, సమూహ రహస్యం, వినియోగదారు పేరు మరియు వినియోగదారు పాస్‌వర్డ్. ఆ ఫీల్డ్‌లు ఒకే ప్రోటోకాల్‌ను వివరిస్తాయి, మరియు వాటి ఏ కలయికా క్లయింట్‌ను మరొకటి మాట్లాడేలా చేయలేదు.

అందుకే సైఫర్ జాబితాను విస్తరించడం లేదా ప్రమాణపత్ర తనిఖీలను ఆఫ్ చేయడం ఈ రకమైన వైఫల్యాన్ని ఎప్పటికీ సరిచేయదు. ఆ మార్పులు గేట్‌వే వినని చర్చలను బలహీనపరుస్తాయి.

గేట్‌వేకు సరిపోయే క్లయింట్ ఎంపిక

Check Point గేట్‌వే కోసం ఆ గేట్‌వే విడుదల కోసం నిర్మించిన SNX ప్యాకేజీని ఉపయోగించండి, దాన్ని విక్రేత తన రిమోట్ యాక్సెస్ పత్రాలతో పాటు ప్రచురిస్తాడు. పాత SNX బిల్డ్‌లు ప్రస్తుత పంపిణీలలో తరచుగా విఫలమవుతాయి ఎందుకంటే ఇక ఇన్‌స్టాల్ చేయని 32-bit లైబ్రరీలను ఆశిస్తాయి, మరియు వదిలివేసిన ప్యాకేజీని ప్యాచ్ చేయడం సాధారణంగా మద్దతు ఉన్న ప్లాట్‌ఫారమ్‌లో మద్దతు ఉన్న క్లయింట్‌ను నడపడం కంటే అధ్వానం.

Aventail క్లయింట్లు చాలా కాలం క్రితమే మద్దతు కోల్పోయాయి. అలాంటి గేట్‌వే ఇప్పటికీ సేవలో ఉన్న చోట, సంస్థ ప్రారంభిస్తే బ్రౌజర్ పోర్టల్, లేదా మద్దతు ఉన్న ఆపరేటింగ్ సిస్టమ్‌లో విక్రేత మద్దతు ఉన్న క్లయింట్ వాస్తవ ఎంపికలు.

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