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 જમાવવાનું કારણ નહીં.