PPP CHAP એકલું MPPE ની આવશ્યકતા કેમ પૂરી કરી શકતું નથી

એન્ક્રિપ્શન પર ભાર મૂકતું PPTP પ્રોફાઇલ સામાન્ય રીતે એક જ જગ્યાએ નિષ્ફળ જાય છે: PPP એવી પ્રમાણીકરણ આપલે પર સંમત થાય છે જે કદી MPPE ને જોઈતી કી સામગ્રી ઉત્પન્ન કરતી નથી. ટનલ અડધી જીવંત દેખાય છે, પાસવર્ડ સ્વીકારાય છે, અને કોઈ પણ ટ્રાફિક પસાર થાય તે પહેલાં લિંક તૂટી જાય છે. કંઈક જોડાય ત્યાં સુધી CHAP ડ્રોપડાઉન તરફ હાથ લંબાવવો ખરા ખામીને છુપાવે છે, અને તે પ્રમાણીકરણ પદ્ધતિ અને સંરક્ષણ નીતિ વચ્ચેનો કરાર છે. નીચેની તપાસો એવી રીતે ગોઠવેલી છે કે દરેક આગલી કરતાં સસ્તું કારણ બાકાત કરે.

એક PPTP કનેક્શનની અંદર બે વાટાઘાટો ચાલે છે

PPTP GRE ટનલની અંદર સામાન્ય PPP સત્ર વહન કરે છે, અને બંને અલગ અલગ વાટાઘાટ કરે છે. બાહ્ય સ્તર નક્કી કરે છે કે પેકેટ કેવી રીતે એન્કેપ્સ્યુલેટ થાય અને કયો નિયંત્રણ ચેનલ અસ્તિત્વમાં છે; આંતરિક PPP સત્ર નક્કી કરે છે કે સાથી કોણ છે અને ઉપર કઈ સુરક્ષા ચાલે છે. તેથી પાસવર્ડની માંગ ફક્ત આંતરિક સ્તર વિશે કંઈક સાબિત કરે છે, અને પૂર્ણ થયેલો બાહ્ય હેન્ડશેક બંનેમાંથી કોઈના વિશે કંઈ સાબિત કરતો નથી. પ્રોફાઇલ અહીં નિષ્ફળ જાય છે કારણ કે લોકો ટનલ ડિબગ કરે છે જ્યારે મતભેદ PPP ની અંદર બેઠો હોય છે.

સાદો CHAP એ RFC 1994 માંની પડકાર-પ્રતિસાદ આપલે છે, જે વહેંચાયેલ રહસ્ય અને બીજું કંઈ નહીં પર બનેલી છે. MS-CHAPv2 એ અલગ સંદેશા અને અલગ આઉટપુટ ધરાવતી બીજી આપલે છે, જે RFC 2759 માં માનકીકૃત છે. બે નામોમાંનો વહેંચાયેલ શબ્દ એ જ એક વસ્તુ છે જે તેમની વચ્ચે તાર પર સામાન્ય છે. બંનેમાંથી કોઈ નામ કહેતું નથી કે આપલે શું ઉત્પન્ન કરે છે, અને તે જ એકમાત્ર મહત્વનો ભાગ છે.

તેથી જ ફક્ત CHAP લેબલવાળો વિકલ્પ જૂના પ્રોફાઇલમાં અસ્પષ્ટ છે. જ્યારે સર્વર MS-CHAPv2 ઈચ્છે છે અને ક્લાયન્ટ સાદો CHAP ઓફર કરે છે, ત્યારે લિંક નિયંત્રણ હજી પૂર્ણ થઈ શકે છે અને પાસવર્ડ હજી સ્વીકારાઈ શકે છે. નિષ્ફળતા પછી આવે છે, જ્યારે સર્વર એવી આપલેમાંથી સંરક્ષણ કી મેળવવાનો પ્રયાસ કરે છે જેણે કંઈ ઉત્પન્ન કર્યું નથી.

જરૂરી પદ્ધતિને તે જે કી ઉત્પન્ન કરી શકે તેની સાથે મેળવો

MPPE કી સામાન્ય રીતે PPP ની મિલકત નથી. Microsoft CHAP કુટુંબ માટે વ્યુત્પત્તિ RFC 3079 માં નિર્દિષ્ટ છે, અને તે ઇનપુટ તરીકે વહેંચાયેલ રહસ્યને બદલે MS-CHAP આપલેનું આઉટપુટ લે છે. EAP પદ્ધતિઓ અલગ માર્ગે એ જ જગ્યાએ પહોંચે છે, જ્યાં પ્રમાણીકરણ સર્વર કીને MS-MPPE-Recv-Key અને MS-MPPE-Send-Key એટ્રિબ્યુટ તરીકે પાછી આપે છે. સાદો CHAP બંને માર્ગોમાં ક્યાંય દેખાતો નથી, અને આ અસંગતિ હોવાનું આખું કારણ એ જ છે.

જે ગોઠવણી MPPE માંગે છે પણ કી આપી શકે તેવી દરેક પદ્ધતિ નકારે છે તે આંતરિક રીતે વિરોધાભાસી છે. pppd એ વિરોધાભાસ લિંક નકારીને ઉકેલે છે, કી શોધીને નહીં, તેથી દેખાતું પરિણામ એ સત્ર છે જે પ્રમાણીકરણ કરે છે અને પછી નેટવર્ક તબક્કામાં સમાપ્ત થાય છે. સર્વર જ્યાં સુધી કંઈ વ્યુત્પન્ન કરતી એકમાત્ર પદ્ધતિઓ નકારે છે ત્યાં સુધી ક્લાયન્ટને ફરી પ્રયાસ કરવાથી તે બદલાશે નહીં.

તેમાંથી નીકળતો નિયમ ટૂંકો છે: જો પ્રોફાઇલ MPPE માંગે છે, તો પદ્ધતિ MS-CHAP નો પ્રકાર અથવા એવી EAP પદ્ધતિ હોવી જોઈએ જેની કી સર્વર પાછી આપે છે. ફક્ત MS-CHAPv2 નકારવાથી તે લાગુ થતું નથી, કારણ કે MS-CHAPv1 પણ કી વ્યુત્પન્ન કરે છે અને અલગથી નકારવામાં ન આવે ત્યાં સુધી ઉપલબ્ધ રહે છે; બંને નકારવાથી સાદો CHAP અને PAP બાકી રહે છે, જે કંઈ વ્યુત્પન્ન કરતા નથી અને આવશ્યકતાને અપૂર્ણ કરે છે. તમને ન ગમતી પદ્ધતિઓની યાદી કરવાને બદલે સ્વીકૃત પદ્ધતિનું સ્પષ્ટ નામ આપો. ક્લાયન્ટ જોડાય તે માટે એન્ક્રિપ્શનની આવશ્યકતા છોડી દેવી સુધારો નહીં, અવનતિ છે.

ક્લાયન્ટ સંપાદિત કરતા પહેલાં સર્વરના વિકલ્પો વાંચો

આમાંના મોટાભાગના અસંગતિ સર્વર પર બે ફાઇલોમાં દેખાય છે, અને તેમને વાંચવાનો ખર્ચ ક્લાયન્ટ ફરી બનાવવા કરતાં ઓછો છે. Linux PPTP એન્ડપોઇન્ટ પર સંબંધિત સેટિંગ્સ pppd વિકલ્પ ફાઇલમાં રહે છે જે pptpd પસાર કરે છે. તેને સર્વર પર ચલાવો, ક્લાયન્ટ સ્થિતિ સ્ક્રીન પરથી નહીં. જે લીટીઓ સંરક્ષણ મોડ માંગે, નકારે અથવા નામ આપે તેનાથી શરૂ કરો:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

આઉટપુટને ફ્લેગની યાદી નહીં, કરાર તરીકે વાંચો. જે લીટી MPPE માંગે છે પણ MS-CHAP ના બંને પ્રકાર નકારે છે તેને કોઈ પણ ક્લાયન્ટ પૂરી કરી શકતું નથી, અને MS-CHAP પદ્ધતિ માટે આવશ્યકતા ખૂટે તો કી ન આપતી આપલે માટે દરવાજો ખુલ્લો રહે છે. પછી તપાસો કે કોને પ્રમાણીકરણની પરવાનગી છે, જે રહસ્ય ફાઇલ નક્કી કરે છે:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

કંઈ પણ બદલતા પહેલાં ત્રણ મૂલ્યો લખો: બાહ્ય પ્રોટોકોલ, સર્વર જે પ્રમાણીકરણ પદ્ધતિ માંગે છે, અને સંરક્ષણ ફરજિયાત છે કે વૈકલ્પિક. તે ત્રણ પછીના દરેક નિર્ણયને નક્કી કરે છે, અને ક્લાયન્ટ સંવાદમાંથી તેમને અનુમાન કરવો એ પ્રોફાઇલ અડધું ગોઠવાયેલું રહેવાનો માર્ગ છે. કામ કરતી વખતે ફાઇલ ખુલ્લી રાખો, કારણ કે આગલા વિભાગને એ જ ત્રણ મૂલ્યોની જરૂર છે.

PPP તબક્કા પ્રમાણે નિષ્ફળતા શોધો

PPP નિષ્ફળતાઓ તબક્કામાં જણાવે છે, અને તબક્કો કહે છે કે કરારની કઈ કલમ તૂટી. જે લિંક કદી લિંક નિયંત્રણ છોડતી નથી તેમાં એન્કેપ્સ્યુલેશન અથવા વાટાઘાટની સમસ્યા છે, જ્યારે જે પ્રમાણીકરણ કરીને પછી મરે છે તેમાં સામાન્ય રીતે નીતિ અથવા કીની સમસ્યા હોય છે. જે લિંક ઉપર રહે છે અને કંઈ વહન કરતી નથી તે રૂટિંગ તરફ આગળ વધી છે, જે અલગ તપાસ છે.

જર્નલ તબક્કાની લીટીઓ રાખે છે, અને તે ઊંચા ડિબગ સ્તર કરતાં વધુ ઉપયોગી છે. PPP પ્રક્રિયાઓ અને સંરક્ષણ સંદેશા માંગો, પછી બીજા કંઈ પહેલાં પ્રમાણીકરણ પરિણામ વાંચો. છેલ્લી લીટીઓ સામાન્ય રીતે નકારનારી કલમનું નામ આપે છે:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

તે આઉટપુટમાં, પહેલાં પ્રમાણીકરણ પરિણામ અને પછી સંરક્ષણ માંગવામાં આવ્યું હતું પણ વાટાઘાટ ન થઈ એવી ફરિયાદ શોધો. બીજો સંદેશ ઉપરના વિરોધાભાસની સહી છે, અને સર્વર જ્યાં સુધી કી ઉત્પન્ન કરી શકતી એકમાત્ર પદ્ધતિ નકારે છે ત્યાં સુધી કેટલીય વાર ફરી પ્રયાસ કરવાથી તે સાફ થતું નથી. બે જાળ નામ આપવા યોગ્ય છે: તબક્કાની લીટીઓ વાંચ્યા વિના ડિબગ સ્તર વધારવાથી ઘોંઘાટ થાય છે, અને પડકાર સામગ્રી કે પાસવર્ડ પકડવાથી ગોઠવણીનું કામ ઓળખપત્ર લીકમાં ફેરવાય છે. કોઈ પણ વિકલ્પ બદલતા પહેલાં તે તબક્કો નોંધો.

જૂનું એન્ડપોઇન્ટ બંધ થાય તે પહેલાં નિકાસની યોજના કરો

MPPE એ ઐતિહાસિક લિંક સંરક્ષણ પદ્ધતિ છે, અને તેની હાજરી PPTP ને નવા તૈનાતી માટે સમજદાર પસંદગી બનાવતી નથી. Microsoft નું વર્તમાન માર્ગદર્શન પહેલેથી જ નવા દૂરસ્થ ઍક્સેસ રોલઆઉટ માટે PPTP અને પૂર્વ-વહેંચાયેલ કી સાથેના L2TP/IPsec સામે સલાહ આપે છે. જૂનું એન્ડપોઇન્ટ જીવંત રાખવું એ હાલની સેવા વિશેનો નિર્ણય છે, આગલી માટેનો નમૂનો નહીં.

જ્યારે એન્ડપોઇન્ટ રહેવું પડે, ત્યારે કરાર લખો: બાહ્ય પ્રોટોકોલ, જરૂરી પ્રમાણીકરણ પદ્ધતિ, ફરજિયાત સંરક્ષણ, અને જે ક્લાયન્ટ આવૃત્તિ તેની વાટાઘાટ કરે છે. જ્યારે તે જઈ શકે, ત્યારે જૂનું પ્રોફાઇલ સ્પર્શતા પહેલાં બદલીના ગેટવે ઓળખ, તેનું ક્લાયન્ટ પ્રમાણીકરણ અને ઓળખપત્ર ક્યાં રહેશે તે પસંદ કરો. પછી રૂટ, DNS અને દરેક વપરાશકર્તાને જે સંસાધનોનો અધિકાર છે તેની યોજના કરો. ઇચ્છિત ક્લાયન્ટને કાર્યરત કનેક્શન સામે નહીં, માલિકની આવશ્યકતાઓ સામે ચકાસો.

ઇરાદાપૂર્વકનો અસ્વીકાર અસ્વીકાર જ રહેવો જોઈએ, કારણ કે પરીક્ષણ પાસ કરાવવા માટે અસુરક્ષિત મોડમાં પાછા જવું નીતિની નિષ્ફળતાને જાહેર થવામાં ફેરવે છે. પૂર્ણ થયેલી સ્થિતિ એ સમર્થિત, દસ્તાવેજીકૃત કરાર છે, એક જૂનું કનેક્શન સફળ કરાવતો નાનામાં નાનો ફેરફાર સમૂહ નહીં. બદલી સમાન તપાસો પાસ ન કરે ત્યાં સુધી જૂનું પ્રોફાઇલ તેની જગ્યાએ, ન વપરાયેલું અને દસ્તાવેજીકૃત રાખો.