GCP HA VPN FortiGate ને નકારે છે: સ્થાનિક ID પ્રકાર મેળ ખાતો નથી
Google ફક્ત પૂર્વ-શેર કરેલ કી જ નહીં, FortiGate જે ઓળખ દાવો કરે છે તે પણ સરખાવે છે. FQDN સ્થાનિક ID એ ચકાસણીમાં નિષ્ફળ જાય છે, જ્યારે લોગ હજી પ્રમાણીકરણ કહે છે.
Google Cloud HA VPN તરફથી AUTHENTICATION_FAILED સામાન્ય રીતે લોકોને પૂર્વ-શેર કરેલ કી તરફ પાછા મોકલે છે, અને કી સામાન્ય રીતે સાચી હોય છે. ટનલ 1 તબક્કે અટકી જાય છે કારણ કે Google બીજું પણ સરખાવે છે: IKE આદાન-પ્રદાન દરમિયાન સાથી જે ઓળખ દાવો કરે છે. FortiGate પર એ ઓળખ કોઈ સરનામું સંપાદિત કર્યા વિના પ્રકાર બદલી શકે છે. કી બે વાર ફરી દાખલ કર્યા પછી લોગને ઓળખ-અસંગતિ તરીકે વાંચો.
એક નિષ્ફળતા, બે ચકાસણી
IKE સાથીને બે અલગ પગલાંમાં ચકાસે છે. પૂર્વ-શેર કરેલ કી સાબિત કરે છે કે બંને છેડા પાસે એક જ રહસ્ય છે, અને દાવો કરેલ ઓળખ જવાબદાતાને જણાવે છે કે સાથી પોતાને કોણ કહે છે. Google એ ઓળખને જે સાથી સાથે તેને ગોઠવવામાં આવ્યું હતું તેની સામે ચકાસે છે. એકલું છોડી દેવામાં આવે તો FortiGate તેના આઉટગોઇંગ ઇન્ટરફેસ પરથી ઉતરી આવેલ સરનામા-આધારિત ઓળખ મોકલે છે, અને સરખામણી કોઈને ખબર પડ્યા વિના પસાર થઈ જાય છે.
બંને પગલાં લોગમાં એક જ ડોલમાં આવે છે, જે એ પરિચિત ચક્ર સમજાવે છે: ઓળખનો પેલોડ કોઈ વાંચે તે પહેલાં કી ચાર વાર ફરી ટાઇપ કરવી.
FortiGate ઓળખના પેલોડમાં શું મૂકે છે
મુશ્કેલી ત્યારે શરૂ થાય છે જ્યારે કોઈ સ્થાનિક ID સેટ કરે છે જેથી બંને બાજુઓ સંમત થાય. તાજેતરના FortiOS બિલ્ડ તે ઓળખને સંપૂર્ણ લાયક ડોમેન નામ તરીકે ચિહ્નિત કરે છે, પછી ભલે દાખલ કરેલું મૂલ્ય બિંદુવાળું સરનામું હોય. તેથી Google સરનામાની અપેક્ષા રાખતી વખતે FQDN ઓળખ મેળવે છે, અને સત્ર નકારી કાઢે છે. સંદેશમાં કંઈ જ કહેતું નથી કે કયો અડધો ભાગ નિષ્ફળ ગયો, તેથી અહેવાલ પ્રમાણીકરણ નિષ્ફળતા તરીકે વંચાય છે.
IKE ડિબગિંગ ચાલુ કરીને તેને એક વાર પુનઃઉત્પન્ન કરો અને ફાયરવોલ ખરેખર જે ઓળખ પેલોડ મોકલે છે તે વાંચો.
એ જ પાસમાં ત્રણ સસ્તી હકીકતોની પુષ્ટિ કરો: બંને છેડા વાપરે છે તે IKE આવૃત્તિ, અદ્રશ્ય અંતિમ અક્ષરો સહિત ચોક્કસ કી, અને Google જે સાથી-સરનામાની અપેક્ષા રાખે છે. તે અલગ પ્રશ્નોના જવાબ આપે છે, અને મેળ ખાતી કી ઓળખ વિશે કંઈ કહેતી નથી.
વિકલ્પો, અને દરેકની કિંમત
દરેક માર્ગ અલગ સ્તર સુધારે છે, અને એક પણ દરેક ડિપ્લોયમેન્ટ માટે ઉપલબ્ધ નથી.
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
ફાયરવોલ પર ઓળખ સુધારવી એ સૌથી સ્વચ્છ જવાબ છે જ્યાં ફર્મવેર તમને પ્રકાર પસંદ કરવા અને મૂલ્ય રાખવા દે છે. ક્ષેત્ર કેટલાક બિલ્ડમાં છે અને અન્યમાં પ્રકાર ખોટી રીતે ભરે છે, તેથી પ્રકાશન નોંધો પર ભરોસો કરવાને બદલે તમારી આવૃત્તિ ચકાસો.
વાટાઘાટ ઇન્ટરફેસ પર રૂટ કરી શકાય તેવું જાહેર સરનામું દસ્તાવેજીકૃત ઉપાય છે, કારણ કે ત્યારે ડિફોલ્ટ ઓળખ Google જે ધારે છે તેની સાથે મેળ ખાય છે અને કોઈ ઓવરરાઇડની જરૂર પડતી નથી. જો ફાયરવોલ આવું સરનામું રાખી શકે તો મોટાભાગના ડિપ્લોયમેન્ટ અહીં જ આવીને અટકે છે.
તમે જે ઉત્પન્ન કરો છો તેની માન્યતા ચકાસતા સાથી પર સમાપ્ત કરવું એ ટોપોલોજી પરિવર્તન છે. તેને વધુ મીઠા વર્ણનવાળા ઉપાય તરીકે નહીં, ડિઝાઇન નિર્ણય તરીકે લો.
જ્યારે NAT એક વિકલ્પ દૂર કરે છે
NAT પાછળ જાહેર-સરનામાનો માર્ગ અદૃશ્ય થાય છે, અને જે બાકી રહે છે તે તમે નિયંત્રિત ન કરતા ફર્મવેર વર્તન પર આધાર રાખે છે. આ એ બિંદુ છે જ્યાં અપગ્રેડ, સાથીને ખસેડવો કે બીજું ક્લાઉડ એન્ડપોઇન્ટ સ્વીકારવા વચ્ચે જાણી જોઈને પસંદગી કરવી જોઈએ. આ ત્રણ અલગ બજેટ છે, અને અકસ્માતે એક પસંદ કરવું એ જ રીતે કામચલાઉ ઉપાય આર્કિટેક્ચર બની જાય છે. પસંદગી અને તેનું કારણ ટનલની બાજુમાં લખો.
આમાંથી કંઈપણ અર્થઘટન કરતા પહેલાં, Google બાજુ પર ટનલની સ્થિતિની પુષ્ટિ કરો અને એ પણ કે IKE ફક્ત રસ્તામાં ફેંકાઈ રહ્યું નથી. ફેંકાયેલ પેકેટ સમય પૂરો થવાથી બંધ થાય છે; તે નકાર ઉત્પન્ન કરતું નથી.
જ્યાં સુધી તે કામ કરે ત્યાં શું નોંધવું
ટનલ છેલ્લે ઉપર આવી ત્યારે જે ઓળખ પ્રકાર, તેનું મૂલ્ય, ફર્મવેર આવૃત્તિ અને સાથી-સરનામું અમલમાં હતા તે નોંધો. ફર્મવેર અપડેટ ડિફોલ્ટ ફરી બદલી શકે છે, અને આગલી નિષ્ફળતા બરાબર કી-અસંગતિ જેવી દેખાશે. ઓળખ કી અને સાથી-સરનામાની બાજુમાં સંગ્રહિત હોય તો આગલી વ્યક્તિ સસ્તી ચકાસણીઓથી શરૂ કરે છે.
એ નોંધ એ પણ જાણવાનો એકમાત્ર રસ્તો છે કે આગલા અપગ્રેડ પછી પણ ઉપાયની જરૂર છે કે નહીં.