L2TP પર NO_PROPOSAL_CHOSEN? પહેલા ગેટવે સ્કેન કરો

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

સંદેશ શું બાકાત રાખે છે

અસ્વીકાર મુખ્ય મોડમાં, કોઈપણ L2TP અથવા PPP વિનિમય પહેલાં થાય છે, તેથી ટનલ અને વપરાશકર્તા ડેટાબેઝને પૂછવામાં આવ્યા નથી. ફેઝ 1 એન્ક્રિપ્શન, અખંડિતતા અને Diffie-Hellman જૂથ પર વાટાઘાટ કરે છે. ફેઝ 2 ડેટા માટે ESP પ્રસ્તાવ પર વાટાઘાટ કરે છે. ફેઝ 1 ની નિષ્ફળતા ફેઝ 2 નું PFS સેટિંગ બદલીને સુધારી શકાતી નથી, અને પૂર્ણ થયેલી IKE એસોસિએશન સાબિત કરતી નથી કે ESP પ્રસ્તાવ યોગ્ય છે.

સિન્ટેક્સ સંપાદિત કરતા પહેલાં બેકએન્ડ નોંધો: ipsec --version. libreswan અને strongSwan સમાન અલ્ગોરિધમ માટે પ્રસ્તાવની જુદી જુદી જોડણી સ્વીકારે છે.

પછી અસ્વીકારને સંદર્ભમાં આની સાથે વાંચો: journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

ગેટવેને તેના ટ્રાન્સફોર્મ સેટ માટે સ્કેન કરો

સ્કેનર ગેટવેને સીધું પૂછે છે કે તે કયા ટ્રાન્સફોર્મ પર વાટાઘાટ કરશે. પહેલા સ્થાનિક IPsec સેવા બંધ કરો જેથી પ્રોબ તમારા પોતાના ક્લાયન્ટ સાથે સ્પર્ધા ન કરે, પછી SA લીટીઓ વાંચો. સૂચિને સામેની બાજુ વિશેના પુરાવા તરીકે ગણો, બધું એકસાથે સક્રિય કરવાના મેનુ તરીકે નહીં.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

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

સુરક્ષા બંધ ન કરતાં ઓવરલેપ મેળવો

ફક્ત એ જ ટ્રાન્સફોર્મ દાખલ કરો જે સ્કેન અને તમારી નીતિ બંનેમાં દેખાય. નીચેનું ઉદાહરણ ફેઝ 1 માં 3DES, SHA1 અને MODP1024 ઑફર કરતા ગેટવેને દર્શાવે છે. બેકએન્ડની ચેતવણી ધ્યાનમાં લો: libreswan 4.x modp1024 જૂથને કમ્પાઇલ કરતું નથી, તેથી આ strongSwan અથવા DH2 સપોર્ટ સાથેના libreswan બિલ્ડને લાગુ પડે છે. ક્લાયન્ટ બગડેલું છે તેવું તારણ કાઢતા પહેલાં આવૃત્તિ ચકાસો.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

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

ફરી પ્રયાસ કરતા પહેલાં ડિમન અને પોર્ટ તપાસો

NetworkManager-l2tp પોતાનું xl2tpd ઇન્સ્ટન્સ શરૂ કરે છે. જો સિસ્ટમ સેવા પહેલેથી UDP 1701 ધરાવે છે, તો ક્લાયન્ટ ક્ષણિક સ્રોત પોર્ટ પર પાછું જાય છે, જે RFC 3193 મંજૂરી આપે છે અને કેટલાક સર્વર શાંતિથી કાઢી નાખે છે. આગલા પ્રયાસ પહેલાં સોકેટનો માલિક તપાસો.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

બાસી જનરેટ થયેલા સિક્રેટ બીજું શાંત કારણ છે. અહીંની ફાઇલો /etc/ipsec.d/ જૂના કનેક્શન માટે નામ આપેલી ફાઇલો તેમને બનાવનાર પ્રોફાઇલ કરતાં વધુ જીવી શકે છે, તેથી જેમને કંઈ સંદર્ભિત કરતું નથી તેમને દૂર કરો અને ફરી પ્રયાસ કરો.

છેલ્લે, સલાહ ક્યાંથી આવી તે ચકાસો. ipsec.conf IKEv1 XAuth માટે લખાયેલી ફાઇલ અલગ પ્રકારના VPNનું વર્ણન કરે છે, અને L2TP પ્રોફાઇલમાં તેનો પ્રસ્તાવ જ એકમાત્ર ખોટી લીટી નથી. તમે દાખલ કરેલો ટ્રાન્સફોર્મ સેટ પ્રોફાઇલની બાજુમાં નોંધો, જેથી આગલી વ્યક્તિ પ્રોબનું પુનરાવર્તન ન કરે.