Cloud VPN થી Cisco ASA: પ્રસ્તાવની અસમાનતા પછી પુનર્નિર્માણ

Cisco ASA સામેના છેડે હોય તેવા Cloud VPN ટનલ પર NEGOTIATION_FAILURE લગભગ હંમેશા પ્રસ્તાવ કે સિલેક્ટરની અસમાનતા હોય છે, અને પહેલી ઉપયોગી વાત એ છે કે કોઈ સંપાદન તેને સુધારશે નહીં. ટનલ ઑબ્જેક્ટ બનાવતી વખતે Cloud VPN IKE પ્રસ્તાવ નિશ્ચિત કરી દે છે. અલ્ગોરિધમ જ્યાં છે ત્યાં બદલવા માટે કોઈ ફીલ્ડ નથી, તેથી સુધારો એટલે ડિલીટ કરીને નોંધેલા શરૂઆતના બિંદુ સાથે ફરી બનાવવું. તેને પુનર્નિર્માણ તરીકે લો, પછી કામ અનુમાનથી ભરેલી બપોરને બદલે ચેકલિસ્ટ બની જાય છે.

કંઈ પણ ડિલીટ કરતા પહેલા નિષ્ફળતા વાંચો

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

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

બંને કોન્ફિગરેશન હજી હયાત હોય ત્યારે નોંધી લો

ટનલ ડિલીટ કરવામાં અડધી મિનિટ લાગે છે અને તમારી પાસેનો એકમાત્ર પુરાવો નાશ પામે છે. તે પહેલા સ્થાનિક અને દૂરના સિલેક્ટર, પીઅરનું સરનામું, શેર્ડ સિક્રેટ કોની પાસે છે, અને ASAનું crypto map કે IKEv2 પ્રોફાઇલ લખી લો. ASA બે અલગ પ્રશ્નોના જવાબ આપે છે: શું કોન્ફિગર કરેલું છે અને અત્યારે શું ઉપર છે:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Googleની બાજુએ કન્સોલ સારાંશને બદલે ટનલ ઑબ્જેક્ટ વાંચો, કારણ કે પીઅરનું સરનામું અને સિલેક્ટર ફીલ્ડ એ જ મૂલ્યો છે જે તમારે બરાબર પુનરુત્પાદિત કરવા પડે:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

પહેલા ડિલીટ પહેલા એ મૂલ્યો ટિકિટમાં નાખો. નીચેનું પુનર્નિર્માણ ફક્ત એટલા માટે કામ કરે છે કે તમે એક જાણી જોઈને કરેલા ફરક સાથે એ જ ઑબ્જેક્ટ ફરી બનાવી શકો છો.

જે અલ્ગોરિધમ પર એક પક્ષ વાટાઘાટ કરવાનો ઇનકાર કરે છે

Cloud VPN પરંપરાગત પીઅરની જેમ IKEv1 અલ્ગોરિધમની શ્રેણીમાંથી પસંદ કરતું નથી. તે જે પીઅર સેટિંગ્સની અપેક્ષા રાખે છે તે નિશ્ચિત છે: એન્ક્રિપ્શન માટે aes-cbc-128, ઇન્ટિગ્રિટી અને PRF બંને માટે sha1-96, Diffie-Hellman જૂથ 2, ફેઝ 1 માટે 36,600 સેકન્ડ અને ફેઝ 2 માટે 10,800 સેકન્ડ. ASA નીતિએ બરાબર એ જ સમૂહ આપવો પડે. ASA પર બીજો પ્રસ્તાવ નુકસાન કરતો નથી, જો મેળ ખાતો પ્રસ્તાવ પણ યાદીમાં હોય.

IKEv2 બંને પક્ષોને વધુ જગ્યા આપે છે, પણ નિયમો એ જ આકાર જાળવે છે: PFS ચાલુ કરો, ટનલ જે DH જૂથને ટેકો આપે તે પસંદ કરો, અને પ્રસ્તાવની યાદી એટલી ટૂંકી રાખો કે અસમાનતા સ્પષ્ટ દેખાય. Cloud VPN પર ASA પીઅર એટલે સ્થિર રૂટિંગ પણ, તેથી સુરક્ષિત પ્રીફિક્સને BGPને સોંપવાને બદલે યોજીને યાદીમાં મૂકવા પડે.

બીજા વેન્ડરના ટેમ્પલેટમાંથી કોપી કરેલું લાઇફટાઇમ અહીં સામાન્ય ખોટો વળાંક છે. Google આ મૂલ્યોને આવશ્યક પીઅર સેટિંગ્સ તરીકે પ્રકાશિત કરે છે, તેથી તે જ સેટ કરો; નાનું મૂલ્ય ASA જે ઈચ્છે તે સુધી ઉપર વાટાઘાટ નથી થતું.

ડિલીટ કરો, ફરી બનાવો અને જૂની સ્થિતિ સાફ કરો

ગેટવે નહીં, ટનલ ડિલીટ કરો, અને Cloud VPN બદલીને જે નામ આપે છે તે નોંધો, કારણ કે નામ ફાળવાય છે, ફરી વપરાતા નથી. નોંધેલા મૂલ્યો અને એ જ પીઅર સરનામા સાથે તેને ફરી બનાવો, પછી મેળ ખાતો પ્રસ્તાવ ASA નીતિની યાદીમાં ઉમેરો.

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

clear crypto ikev2 sa
clear crypto ipsec sa

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

સિલેક્ટર અરીસાની જેમ મળે છે, પછી કાઉન્ટર નક્કી કરે છે

ફેઝ 2 ફક્ત ત્યારે કામ કરે છે જ્યારે બંને છેડા સુરક્ષિત સરનામાં પર સહમત હોય, અને એ સહમતિ વહેંચાયેલી નહીં પણ અરીસા જેવી હોય છે. Googleનું સ્થાનિક સિલેક્ટર એ સિલેક્ટર સાથે મેળ ખાવું જોઈએ જેને ASA દૂરનું કહે છે, અને Googleનું દૂરનું સિલેક્ટર એની સાથે જેને ASA સ્થાનિક કહે છે. એક બાજુ 0.0.0.0/0 અને બીજી બાજુ એક જ સબનેટ હોય તેવી ટનલ ફેઝ 1 પસાર કરે છે અને પછી એ જ મુખ્ય ભૂલ સાથે ફેઝ 2માં નિષ્ફળ જાય છે. કોઈ પણ પક્ષ બીજાની યાદી પહોળી કરી શકતું નથી.

નીતિ-આધારિત સિલેક્ટર માટે દરેક પ્રીફિક્સ જોડીની યાદી બનાવો અને યાદી ટિકિટમાં રાખો. પછી પરિસરમાં ઉમેરાયેલા સબનેટ માટે બંને છેડે સંપાદન જરૂરી છે, કારણ કે ASA પરનો નવો રૂટ સિલેક્ટર પહોળો કરતો નથી, અને પરિણામ એ ટનલ છે જે ઉપર છે અને ફક્ત પહેલા દિવસે હયાત પ્રીફિક્સ માટે ટ્રાફિક પસાર કરે છે.

એક હોસ્ટ-થી-હોસ્ટ ફ્લો સાથે પૂરું કરો અને બંને બાજુ બાઇટ કાઉન્ટર વાંચો. ASA પર વધતા અને Google પર સપાટ રહેતા કાઉન્ટર સામાન્ય રીતે એમ કહે છે કે જવાબ બીજા ઇન્ટરફેસમાંથી નીકળે છે, અથવા સિલેક્ટર પરત પ્રીફિક્સને આવરી લેતું નથી. અલ્ગોરિધમ, લાઇફટાઇમ, સિલેક્ટર અને ટનલનું નવું નામ નોંધો, કારણ કે આગલું પ્રસ્તાવ પરિવર્તન આ પુનર્નિર્માણનું પુનરાવર્તન કરે છે અને એ મૂલ્યો તેને ટૂંકું કામ બનાવે છે.