L2TP/IPsec નિષ્ફળ: IPsec, ટનલ પ્રમાણીકરણ કે PPP લોગિનને અલગ કરો

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

ત્રણ પ્રમાણીકરણ તબક્કા, ત્રણ જુદી ઓળખ

IPsec પૂર્વ-વહેંચાયેલ કી કે પ્રમાણપત્ર વાપરીને સાબિત કરે છે કે છેડાઓ કોની પાસે છે. એ ઓળખ મશીનો કે ગેટવેની હોય છે, કીબોર્ડ પરની વ્યક્તિની ક્યારેય નહીં. જ્યારે સહભાગીઓ આ તબક્કે સંમત ન થઈ શકે, ત્યારે કોઈ L2TP પેકેટની આપ-લે જ થતી નથી.

L2TP કંટ્રોલ કનેક્શન બીજી, અલગ ચેલેન્જ-રિસ્પોન્સ આપ-લે ઉમેરી શકે છે, જે બંને છેડે રાખવો પડતો સહિયારો ગુપ્ત સંચાલિત કરે છે.

RFC 2661 એ કંટ્રોલ-કનેક્શન પ્રમાણીકરણને વૈકલ્પિક બનાવે છે, જે સમજાવે છે કે એ જ ભૂલ બે સર્વર પર જુદાં લક્ષણો કેમ ઉત્પન્ન કરે છે. જે ડિપ્લોયમેન્ટે ક્યારેય ટનલ ગુપ્ત ગોઠવ્યું નથી તે તબક્કો સંપૂર્ણ છોડી દે છે; જે એક જ બાજુ ગોઠવ્યું છે તે PPP ઓફર થાય તે પહેલાં નિષ્ફળ જાય છે. પછી PPP વપરાશકર્તાને PAP, CHAP કે MSCHAPv2 વડે પ્રમાણિત કરે છે અને નામ એ ખાતા ભંડારને આપે છે જે સ્થાનિક હોઈ શકે, chap-secrets માં, કે RADIUS પર. એ સ્થાને ખોટો પાસવર્ડ હજી પણ તમને કામ કરતી ટનલ અને નિષ્ફળ સત્ર સાથે જ છોડે છે.

કોન્ફિગ સંપાદિત કરતાં પહેલાં થોભવાનું સ્થાન વાંચો

શરૂઆત ipsec --version થી કરો જેથી ખબર પડે કે સ્ટેટસ આઉટપુટ strongSwan નું છે કે Libreswan નું. પછી સર્વર લોગ વાંચો, ક્લાયન્ટ સંવાદ નહીં, કારણ કે સર્વર નોંધે છે કે કયા તબક્કાએ નકાર્યું.

એક લાઇન સામાન્ય રીતે ટિકિટ નક્કી કરે છે: IKE કે પ્રપોઝલ ફરિયાદ પહેલો તબક્કો છે, કંટ્રોલ-કનેક્શન સંદેશો બીજો તબક્કો છે, અને PPP પદ્ધતિ કે ખાતાનો નકાર ત્રીજો તબક્કો છે. એ લાઇન સમય-છાપ સાથે ટિકિટમાં કૉપી કરો. ક્લાયન્ટ બાજુથી અનુમાન કરવું એ એક જ પુરાવો બગાડે છે જે તમારી પાસે પહેલેથી છે.

કી સામગ્રી અને પાસવર્ડ એ પેસ્ટની બહાર રાખો; તબક્કાનું નામ કામને દિશા આપે છે, અને લીક થયેલી પૂર્વ-વહેંચાયેલ કી ટિકિટને વધુ ખરાબ પરિણામો સાથે ફરી ખોલે છે.

પહેલો તબક્કો: IPsec પાસે એસોસિએશન છે?

strongSwan પર ipsec statusall ચલાવો કે Libreswan પર ipsec whack --status અને શૂન્યેતર કાઉન્ટરવાળું સ્થાપિત ચાઇલ્ડ એસોસિએશન શોધો. ip xfrm state બંને પર કર્નલનું દૃશ્ય બતાવે છે. કાઉન્ટર વધતાં સ્થાપિત SA ની જોડી એટલે પહેલો તબક્કો પૂરો થયો અને તમે આગળ વધી શકો.

એસોસિએશન બિલકુલ ન હોવું પીઅર સરનામું, પ્રપોઝલ સેટ કે પૂર્વ-વહેંચાયેલ કી તરફ નિર્દેશ કરે છે, અને ક્યારેક એવા ઉપકરણ તરફ જે UDP 500 ફરી લખે છે પણ UDP 4500 કાઢી નાખે છે. જે એસોસિએશન સ્થપાય છે અને પછી થોડી સેકન્ડોમાં અદૃશ્ય થાય છે તે સામાન્ય રીતે ક્રેડેન્શિયલ સમસ્યા નહીં, પણ બંને છેડા વચ્ચે લાઇફટાઇમની અસંગતિ હોય છે. કંઈપણ ફરી ટાઇપ કરતાં પહેલાં તપાસો કે બંને બાજુ એન્ક્રિપ્શન અને હેશ પ્રપોઝલની એ જ યાદી બતાવે છે. જો ન બતાવે, તો કોઈ કી ક્યારેય કામ નહીં કરે.

એસોસિએશન ગાયબ હોય ત્યાં થોભો. એ સ્થાને PPP વિકલ્પો સંપાદિત કરવાથી કંઈ બદલાતું નથી અને અસલ ખામી આગલી વ્યક્તિથી છુપાઈ જાય છે.

બીજો તબક્કો: L2TP કંટ્રોલ કનેક્શને પ્રમાણીકરણ કર્યું?

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

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

ફક્ત એ જ સત્ર જે PPP વાટાઘાટ શરૂ કરે છે તેણે ખરેખર ટનલ તબક્કો પાર કર્યો છે.

ત્રીજો તબક્કો: PPP ખાતું નકારી રહ્યું છે?

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

Linux સર્વર પર, ડેમન PPP ને આપતું વિકલ્પ-ફાઇલ તપાસો, સામાન્ય રીતે /etc/ppp/options.xl2tpd, અને ખાતરી કરો કે કઈ પદ્ધતિઓ સ્વીકારાય છે અને ખાતાં ક્યાં ઉકેલાય છે. RADIUS માં હોય પણ સ્થાનિક ગુપ્ત-ફાઇલમાં ન હોય તેવું નામ સ્વચ્છ રીતે નિષ્ફળ જાય છે અને ખોટા પાસવર્ડ જેવું લાગે છે. પછી તપાસો કે ક્લાયન્ટ એવી પદ્ધતિ ઓફર કરે છે જે સર્વર સ્વીકારે, નહીં કે વધુ મજબૂત પદ્ધતિ જેની વાટાઘાટ સર્વર નકારે છે. આ તબક્કો સુધારવા પૂર્વ-વહેંચાયેલ કી બદલવી એ બપોર બગાડે છે અને કંઈ બદલતી નથી.

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