PPTPలో LCPను ప్రత్యర్థి ముగించింది: మొదట MPPE ప్రారంభించండి

లింక్ ప్రామాణీకరణను దాటుతుంది, క్లయింట్ అనుసంధానమైనట్లు నివేదిస్తుంది, ఒక సెకను తర్వాత లాగ్ LCP ప్రత్యర్థిచే ముగించబడింది అని మూసుకుపోతుంది. ఆ పంక్తి GRE సొరంగం లోపలి PPP చర్చల నుండి వస్తుంది, అంటే రవాణా ఇప్పటికే పనిచేస్తోంది మరియు రెండు చివరలు లింక్ ఎంపికలపై ఏకీభవించలేదు. ఇక్కడ పాస్వర్డ్లు మరియు సర్వర్ చిరునామాలు సాధారణంగా నిర్దోషి. మొదట పోల్చవలసినది ఎన్క్రిప్షన్ విధానం, Linuxలో pppd యొక్క ప్రత్యర్థి ఫైలే మొదట చూడవలసిన స్థలం.

LCP వైఫల్యం PPP దశ గురించి ఏం చెబుతుంది

PPTP, PPPను GREలో చుట్టుతుంది: TCP 1723 నియంత్రణ కనెక్షన్ కాల్ను సిద్ధం చేస్తుంది, GRE పేలోడ్ను మోసుకెళ్తుంది, తర్వాత LCP ప్రామాణీకరణ ప్రోటోకాల్, కంప్రెషన్ మరియు MPPE వంటి ఎంపికలను చర్చిస్తుంది. అవసరమైన ఎంపిక అతని వైపు ఆమోదయోగ్యం కానప్పుడు ప్రత్యర్థి LCPను ముగిస్తాడు. CHAP లేదా MSCHAPv2 మార్పిడి పూర్తయి వెంటనే LCP ముగిసే లాగ్ విధాన తిరస్కారం, చేరుకోగలిగే వైఫల్యం కాదు. సొరంగం చర్చలకే చేరుకోకపోతే, LCP పంక్తిని చదవడానికి ముందు pppd మరియు దాని ప్లగిన్ను తనిఖీ చేయండి.

రెండు ముందస్తు షరతులు సులభంగా దాటవేయబడతాయి. pppd బైనరీ ఉండాలి, ప్రత్యర్థి ఫైల్లో పేర్కొన్న PPTP ప్లగిన్ ఇన్స్టాల్ అయి ఉండాలి; ప్యాకేజీ లేకపోతే ఏ ఎంపిక చర్చకు వచ్చే ముందే డయల్ ముగుస్తుంది.

MPPEను అది కోరే వైపు ప్రారంభించండి

నిజమైన నిర్ణయం ఎన్క్రిప్షన్ విధానం ఏ చివరకు చెందుతుంది అనేది. క్లయింట్ MPPEను అందించవచ్చు, కోరవచ్చు లేదా తిరస్కరించవచ్చు, సర్వర్ కూడా అదే ఎంపిక చేస్తుంది. రెండూ కోరితే లింక్ లేస్తుంది; ఒకటి కోరి మరొకటి తిరస్కరిస్తే LCP ముగుస్తుంది.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

డయల్ చేయడానికి ముందు modprobe ppp_mppe ఉపయోగించి మాడ్యూల్ను లోడ్ చేయండి, ఎందుకంటే అది లేకుండా require-mppe-128 విఫలమవుతుంది. Windowsలో సమాన నియంత్రణ VPN ఎంట్రీ యొక్క భద్రతా ట్యాబ్, అక్కడ సర్వర్ ఇచ్చేది అంగీకరించడం బదులు ఎన్క్రిప్షన్ కోరమని క్లయింట్కు చెప్పాలి. సర్వర్ ఇంకా LCPను ముగిస్తే, MPPE తప్పనిసరా, ఐచ్ఛికమా లేదా నిష్క్రియమా అని దాని ఆపరేటర్ను అడగండి, ఎందుకంటే సర్వర్ తిరస్కరించే రక్షణను క్లయింట్ చర్చించలేడు. సందేశం మాయమవ్వాలని ఎన్క్రిప్షన్ను ఆఫ్ చేయడం తప్పు దిశ: ఇది ఈ ప్రోటోకాల్కు ఉన్న ఏకైక రక్షణను తొలగిస్తుంది.

సవరించే ముందు పనిచేసే ప్రత్యర్థి ఫైల్ను సేవ్ చేయండి. తప్పుగా టైప్ చేసిన require-mppe పంక్తి అదే సాధారణ LCP వైఫల్యాన్ని పునరుత్పత్తి చేసి మిమ్మల్ని ప్రారంభానికి పంపుతుంది.

యాప్లెట్ బదులు pppd యొక్క సొంత లాగ్ను చదవండి

డెస్క్టాప్ యాప్లెట్లు డిస్కనెక్ట్ను చూపి కారణాన్ని దాచుతాయి, కాబట్టి ఒక ప్రయత్నం గురించి డీమన్ వివరణను చదవండి. systemd వ్యవస్థల్లో సందేశం జర్నల్కు చేరుతుంది; పాత సెటప్లు సాంప్రదాయ లాగ్ ఫైల్లలో రాస్తాయి.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

రోజంతా పునఃకనెక్షన్ల బదులు ఒకే డయల్ చుట్టూ ఉన్న విండోలో వెతకండి, అప్పుడు తిరస్కరించిన ఎంపిక సులభంగా కనిపిస్తుంది. pppd సాధారణంగా ఎంపిక పేరు మరియు ప్రత్యర్థి సమాధానాన్ని చెబుతుంది, అది మీ ప్రతిపాదనను మార్చాలా లేదా సర్వర్ వైపును దాని షరతు సడలించమని అడగాలా అని తెలియజేస్తుంది. ప్రయత్నాలను సమయ ముద్రలతో ఉంచండి, ఎందుకంటే ఏ పంక్తులు ఏ కాల్కు చెందినవో తెలియకుండా రెండు లాగ్లను పోల్చడం ఉపయోగం లేదు. LCP మార్పిడే కనిపించకపోతే, లోపం గొలుసులో ముందుగా ఉంది మరియు MPPE అనుమానితం కాదు.

పునఃకనెక్షన్లలో సవరణను నిలిపి ఉంచండి: హుక్ పేర్లు మరియు MTU

లింక్ నిలబడిన తర్వాత, పునఃకనెక్షన్ను తట్టుకుంటుందా అని రెండు వివరాలు నిర్ణయిస్తాయి. హుక్లు /etc/ppp/ip-up.d మరియు /etc/network/if-up.d అనే ఫోల్డర్లలో ఉంటాయి, రెండు డైరెక్టరీలను run-parts ప్రాసెస్ చేస్తుంది, దాని ఫైల్నామ్ ఫిల్టర్ చుక్క ఉన్న ఏదైనా తిరస్కరిస్తుంది. అందువల్ల set-pptp.sh అనే స్క్రిప్ట్ దాటవేయబడుతుంది, set-pptp అమలు అవుతుంది. స్క్రిప్ట్ కంటెంట్ను డీబగ్ చేయడానికి ముందు పేరును తనిఖీ చేయండి, ఆపై అదే హుక్ లోపలి నుండి చిన్న MTUను సెట్ చేయండి, తద్వారా ప్రతి కొత్త ppp ఇంటర్ఫేస్ చేతి ఆదేశం లేకుండా దాన్ని వారసత్వంగా పొందుతుంది.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

సెషన్ను ఉద్దేశపూర్వకంగా ముగించడానికి ప్రాసెస్ పేర్లను నమూనా సరిపోల్చడం బదులు pppd నమోదు చేసిన pidను లక్ష్యంగా చేసుకోండి, ఎందుకంటే ppp ఉన్న ప్రతిదాన్ని చంపడం సంబంధం లేని లింక్లను కూడా తెంపేస్తుంది. PPTP పాతబడింది మరియు MS-CHAPv2 బలహీనం, కాబట్టి ఈ తనిఖీలను నడుస్తూనే ఉండాల్సిన లింక్ నిర్వహణగా భావించండి, కొత్త ప్రదేశంలో PPTP అమర్చడానికి కారణంగా కాదు.