PPTP మరియు L2TP/IPsec వినియోగదారు పేరు అడిగే ముందే ఆగిపోతాయి ఎందుకు?
వినియోగదారు పేరు అడగడం రాకపోవడం అంటే PPP ఎప్పుడూ ప్రారంభం కాలేదు, కాబట్టి లోపం రవాణా, కీల మార్పిడి లేదా టన్నెల్ సెటప్లో ఉంది. మళ్లీ ఇన్స్టాల్ చేయడానికి ముందు దశల క్రమాన్ని తనిఖీ చేయండి.
వినియోగదారు పేరు అడగడం రాకపోవడం ఒక నిర్ధారణ బహుమతి: PPP ఇంకా ప్రారంభం కాలేదు, కాబట్టి ఖాతా, పాస్వర్డ్ మరియు డొమైన్ విధానం ఇంకా అడగబడలేదు. PPTP లేదా L2TP/IPsec కనెక్షన్లో టన్నెల్ ఉన్నప్పుడు మరియు సర్వర్ PPP సెషన్ ప్రారంభించిన తర్వాత మాత్రమే క్లయింట్ ఆధారాలను అడుగుతుంది. ఆ క్షణానికి ముందు విఫలమయ్యేది అంతా రవాణా, కీల మార్పిడి లేదా టన్నెల్ సెటప్, ఇది «VPN పాడైంది» కంటే చాలా చిన్న ప్రాంతం.
లేని అభ్యర్థన లోపాన్ని మూడు దశలకు కుదిస్తుంది
కనిపించే విధంగా విజయవంతమైన చివరి దశను రాసుకోండి, ఎందుకంటే ప్రతి దానికి వేరే యజమాని మరియు వేరే పరిష్కారం ఉంటాయి. రెండు దశల ముందే చిక్కుకుని ఉండగా ఖాతా సెట్టింగ్లను ఊహించడం ఒక మధ్యాహ్నం పోయే మార్గం.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
అభ్యర్థన లేకుండా గడువు ముగిసే క్లయింట్కు ఎప్పుడూ IPsec అనుబంధం లభించలేదు, కాబట్టి లోపం IKE లో లేదా మీ ప్యాకెట్లు గేట్వేను చేరుతున్నాయా అనే దానిలో ఉంది. ఆధారాలను ధృవీకరిస్తున్నట్టు తెలిపి తర్వాత పడిపోయే క్లయింట్ సందేశం సూచించిన దానికంటే ముందుకు వెళ్లింది. అభ్యర్థన తర్వాత తిరస్కరణ వస్తే అది PPP ప్రామాణీకరణ, దాని స్థానం ఖాతా గురించిన వ్యాసంలో, ఈ వ్యాసంలో కాదు.
మొదటి దశ: ఫైర్వాల్ నిశ్శబ్దంగా పడవేసే ప్రోటోకాల్
PPTP కి నియంత్రణ ఛానెల్ కోసం TCP 1723 మరియు డేటా మార్గం కోసం IP ప్రోటోకాల్ 47 అవసరం, రెండూ విడివిడిగా ప్రయాణిస్తాయి. చాలా నెట్వర్క్లు 1723 ను ముందుకు పంపి ప్రోటోకాల్ 47 ను పడవేస్తాయి, ఇది చర్చలు జరిపి తర్వాత ఏమీ మోయని టన్నెల్ను సృష్టిస్తుంది. NAT చేసే రౌటర్కు GRE మద్దతు ఉన్న మార్గం కూడా అవసరం, IPv6 మాత్రమే ఉన్న యాక్సెస్ మార్గం ఏ కాన్ఫిగరేషన్లోనూ PPTP ను మోయలేదు.
IPsec పైన L2TP IKE కోసం పోర్ట్ 500 మరియు NAT దాటడానికి పోర్ట్ 4500 ఖర్చు చేస్తుంది, తర్వాత L2TP ట్రాఫిక్ను 1701 లో చుట్టుతుంది, అనుబంధం ఏర్పడ్డాక ESP రక్షిత పేలోడ్ను మోస్తుంది. రెండు నియంత్రణ పోర్టులను అనుమతించి ESP ను అనుమతించకపోతే, శీర్షికలోని లక్షణమే లభిస్తుంది: కనిపించే పురోగతి, తర్వాత ఏ ఆధార సంభాషణకు ముందే మృత క్లయింట్. ఫోన్ హాట్స్పాట్ నుండి పరీక్షించడం క్లయింట్ సమస్యను మార్గ సమస్య నుండి వేరు చేసే చవకైన మార్గం.
రెండో దశ: కీ కాని కీ, అందించబడని ప్రతిపాదన
సరిపోలని ముందస్తు పంచుకున్న కీ వేగంగా మరియు నిశ్శబ్దంగా విఫలమవుతుంది, సాధారణ రూపం తెరపై సరిగ్గా కనిపించే కానీ అతికించిన పంక్తి విరత లేదా చివరిలో ఖాళీ ఉన్న కీ. Linux క్లయింట్లో సంభాషణ తప్పనిసరిగా సత్య మూలం కాదు: NetworkManager యొక్క L2TP ప్లగిన్ రహస్యాలను /etc/ipsec.d/ కింద ఫైళ్లలో ఉంచుతుంది, మరియు /etc/ipsec.secrets ఇప్పటికీ చేర్చే పాత ప్రతి-కనెక్షన్ ఫైల్ మీరు ఇప్పుడే టైప్ చేసిన దాని స్థానంలో ఉపయోగించబడుతుంది. ఆ ఫైల్ను సురక్షిత ప్రదేశానికి కాపీ చేసి, చేరిక మార్గం నుండి తీసివేసి, తర్వాత కీని చేతితో మళ్లీ టైప్ చేయండి.
ఈ దశలో మిగిలిన సగం ప్రతిపాదన. రెండు చివరలు ఒకే 1వ దశ అల్గోరిథం సెట్పై — ఎన్క్రిప్షన్, సమగ్రత మరియు Diffie-Hellman సమూహం — మరియు 2వ దశకు సరిపోయే ESP రూపాంతరాలపై అంగీకరించాలి, లేకపోతే అనుబంధం అసలు ఏర్పడదు. 3DES, SHA1 మరియు MODP1024 మాత్రమే ఇచ్చే గేట్వే బలమైన అల్గోరిథంల కోసం సెట్ చేసిన క్లయింట్ను తిరస్కరిస్తుంది, దాని లాగ్ తిరస్కరించిన రూపాంతరాన్ని పేర్కొంటుంది. సేవను మళ్లీ ప్రారంభించే బదులు లాగ్ చదివితే లాగే అసమతౌల్యాన్ని పేర్కొంటుంది. ఫోరమ్ థ్రెడ్ నుండి అల్గోరిథం స్ట్రింగ్ కాపీ చేయడం బదులు గేట్వేను ఏ రూపాంతరాలపై నిజంగా చర్చలు జరుపుతుందో అడగండి: దాని చిరునామాకు గురిపెట్టిన ike-scan అది చర్చలు జరిపే రూపాంతరాలను తిరిగి ఇస్తుంది. ఏకైక ఆఫర్ మీ విధానం ఇక అనుమతించని క్రిప్టోగ్రఫీ అయితే, సవరణ క్లయింట్ను దిగువకు దించడంలో కాదు, గేట్వేలో ఉంటుంది.
Windows లో కీ మరియు ప్రామాణీకరణ పద్ధతి VPN ప్రొఫైల్లో ఉంటాయి, అసమతౌల్యం ఆధారాల అభ్యర్థన తర్వాత కాదు, ముందే కనిపిస్తుంది. స్వీకర్త Windows Server అయితే, దూర ప్రాప్యత పాత్ర ఇన్స్టాల్ అయి ఉందని, ధృవపత్రం క్లయింట్లు కనెక్ట్ అయ్యే పేరుతో సరిపోతుందని, ఏ పోర్ట్ ఫిల్టర్ పైన ఉన్న ప్రోటోకాల్ల కంటే ఇరుకుగా లేదని నిర్ధారించుకోండి.
మూడో దశ: టన్నెల్ ఉంది, PPP ప్రారంభం కాదు
IKE పూర్తయినా అభ్యర్థన రాకపోతే ఫైర్వాల్ కాదు, టన్నెల్ డీమన్ను చూడండి. L2TP కి UDP 1701 పై వినిపించేది కావాలి — Linux లో xl2tpd లేదా kl2tpd, Windows లో దూర ప్రాప్యత సేవ — ఇన్స్టాల్ అయి ఆపబడిన సేవ క్లయింట్ వైపు నుండి విసిరిన ప్యాకెట్లాగే కనిపిస్తుంది. మీరు ఇప్పటికే ధృవీకరించిన నియమాలను మళ్లీ తెరవడానికి ముందు వినేదాన్ని తనిఖీ చేయండి. తర్వాత PPP చర్చలు జరపాలి, మొదటి LCP మార్పిడే నిశ్శబ్ద వైఫల్యం సాధారణంగా దిగే స్థలం.
ఈ దశలో ఒక ఉచ్చు అసలు నెట్వర్క్ లోపం కాదు: Windows ఇచ్చిన VPN రకం యొక్క ఒక కనెక్షన్ను మాత్రమే ఒకేసారి అనుమతిస్తుంది, కాబట్టి రెండో ప్రయత్నం లోపం 937 ఇస్తుంది, «ఈ రకం మరో కనెక్షన్ వాడుకలో ఉంది». ఇది స్థానిక నియమం, దీన్ని దాటడానికి మార్గం మరో పరికరం, మరో టన్నెల్ రకం, లేదా ఇప్పటికే ఉన్న ఏకైక కనెక్షన్ను పంచుకోవడం.
ఊహించడం బదులు దశల క్రమంలో లాగ్ చదవండి
క్లయింట్ను ఆపి, మళ్లీ ప్రారంభించి, భాగాలను అవి లాగ్ రాసే క్రమంలో చదవండి. అంటే మొదట IPsec డీమన్ — strongSwan లేదా Libreswan, ఏదో ipsec --version చెబుతుంది — తర్వాత L2TP డీమన్, తర్వాత pppd. వైఫల్యానికి ముందు చివరగా రాసిన భాగమే పరిశీలించాల్సిన దశను సూచిస్తుంది, ఎందుకంటే క్రమంలో దాని తర్వాత వచ్చేది ఏదీ నడవలేదు.
సేవ్ చేసిన సెషన్ బదులు కొత్త కనెక్షన్తో ధృవీకరించండి, ఎందుకంటే కాష్ నుండి మళ్లీ కనెక్ట్ అయ్యే క్లయింట్ మార్పిడిలోని భాగాలను దాటవేసి పాత ఫలితాన్ని పునరుత్పత్తి చేయవచ్చు. చేరిక, కీల మార్పిడి, టన్నెల్ మరియు PPP లను ఒక్కొక్కటిగా, అదే క్రమంలో నిర్ధారించుకోండి. అప్పుడు లేని అభ్యర్థన చిక్కుముడి కావడం మాని నిజంగా పని చేయగల జాబితా రెండో వరుస అవుతుంది. ఆ జాబితానే మీరు నెట్వర్క్ బృందానికి ఇచ్చేది, లేకపోతే ప్రారంభం కాని డీమన్లో నివసించే లోపం కోసం ఫైర్వాల్ను తనిఖీ చేయమని వారిని అడిగేవారు.