IPsec ગેટવે માટે WireGuard પ્રોફાઇલ: એના બદલે શું માંગવું

શાંત ગેટવે સાથે હેન્ડશેક સમયસમાપ્તિનો અર્થ સામાન્ય રીતે બે પ્રોટોકોલ જે ક્યારેય મળતા નથી. WireGuard પીઅર Noise બોલે છે જ્યારે IPsec ગેટવે IKEની રાહ જુએ છે. સાચું સરનામું અને પોર્ટ તેને બદલતા નથી.

પ્રોફાઇલમાં એન્ડપોઇન્ટનો ફરી ઉપયોગ કરવો બંનેને જોડતો નથી. આગળનું પગલું ગેટવે ચલાવનાર વ્યક્તિને વિનંતી કરવાનું છે.

પ્રથમ વિનંતી: પ્રોટોકોલ આવૃત્તિ

IPsec એક પરિવારનું નામ આપે છે, એક જ કાર્યપ્રવાહનું નહીં. IKEv2 અને IKEv1 તેમના આદાનપ્રદાન, પ્રમાણીકરણ વિકલ્પો અને નેટવર્ક ફેરફાર દરમિયાન વર્તનમાં ભિન્ન છે. ફક્ત IKEv1 સમાપ્ત કરતું ગેટવે IKEv2 ઓફર કરતા ગેટવે કરતાં તદ્દન અલગ વર્તશે. ક્લાયન્ટ રૂપરેખાંકન તેની સાથે બદલાય છે.

પૂછો કે સેવા કઈ આવૃત્તિ સમાપ્ત કરે છે અને તે ધોરણ-આધારિત અમલીકરણ ચલાવે છે કે પોતાના ક્લાયન્ટ સાથેનો વિક્રેતા પ્રકાર. ઓપરેટિંગ સિસ્ટમના મેનૂ ઘણી વાર તે જવાબને એક લેબલ પાછળ છુપાવે છે. લેબલ એ પ્રોટોકોલ નથી.

બીજી વિનંતી: ક્લાયન્ટની પ્રમાણીકરણ પદ્ધતિ

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

WireGuard ખાનગી કી એમાંની કંઈપણ નથી. તે એક ચોક્કસ હેન્ડશેકમાં વપરાતી Curve25519 કી છે. કોઈ રૂપાંતરણ તેને પ્રમાણપત્ર કે EAP ઓળખપત્ર બનાવતું નથી. જે સાધન વિપરીત દાવો કરે છે તે ફાઇલનું નામ બદલે છે અથવા અસંબંધિત કંઈક ઉત્પન્ન કરે છે.

RFC 7296માં IKEv2 સ્પષ્ટીકરણ વર્ણવે છે કે તે આવૃત્તિના અમલીકરણે શું સમર્થન કરવું જોઈએ. તે અસ્પષ્ટ ઓપરેટર જવાબ માટે સંદર્ભ છે, ક્લાયન્ટ રૂપરેખાંકન માર્ગદર્શિકા નથી.

ત્રીજી વિનંતી: વિશ્વસનીય ઓળખ અને લક્ષ્યો

ગેટવેની ઓળખ એ રીતે માંગો કે જે રીતે ક્લાયન્ટે તેને જોવી જોઈએ, સાથે તેને માન્ય કરતો વિશ્વાસ-એન્કર. પછી પૂછો કે સેવા કયા ખાનગી રેન્જ અને રિઝોલ્વર ધકેલે છે. તે બે જવાબો નક્કી કરે છે કે ટનલ ખરેખર શું વહન કરે છે.

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

એન્ડપોઇન્ટની તપાસ ક્લાયન્ટ ભૂલ કરતાં અલગ પ્રશ્નનો જવાબ આપે છે. સંલગ્નતા વિના પહોંચી શકાય તેવો પોર્ટ પ્રમાણીકરણ તરફ ઇશારો કરે છે, જ્યારે ન પહોંચી શકાય તેવો પોર્ટ માર્ગ તરફ.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

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

જ્યારે બંને પ્રોટોકોલ સહઅસ્તિત્વમાં રહેવા જોઈએ

બંને નેટવર્કનું સંચાલન બંને પ્રોટોકોલ રાખવાનું વાજબી કારણ છે. સામાન્ય રચના WireGuard અને IPsecને અલગ ઇન્ટરફેસ કે અલગ ગેટવે પર સમાપ્ત કરે છે. મંજૂર ટ્રાફિક પછી તેમની વચ્ચે રૂટ થાય છે.

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

તે જે નથી તે પારદર્શક રૂપાંતરણ છે. WireGuard દ્વારા આવતો ટ્રાફિક IPsec ટનલમાં ફરી ઉત્પન્ન થાય છે, અને વચ્ચેની દરેક નીતિ તેના પર લાગુ પડે છે.

પહેલાં સર્વરની પ્રોટોકોલ અને પ્રમાણીકરણ જરૂરિયાતો સ્પષ્ટ કરો. પછી ઓપરેટર જે ક્લાયન્ટ અને નોંધણી માર્ગને સમર્થન આપે છે તે વાપરો, અને તે દરમિયાન ખાનગી કીને વેબ કન્વર્ટરથી દૂર રાખો.