Tinatanggihan ng GCP HA VPN ang FortiGate: hindi tugma ang uri ng lokal na ID
Inihahambing ng Google ang pagkakakilanlang inaangkin ng FortiGate, hindi lang ang paunang ibinahaging key. Nabigo sa pagsusuring iyon ang lokal na ID na FQDN habang sinasabi pa rin ng log na authentication.
Karaniwang ibinabalik ng AUTHENTICATION_FAILED mula sa Google Cloud HA VPN ang mga tao sa paunang ibinahaging key, at karaniwang tama ang key. Natigil ang tunnel sa yugto 1 dahil may iba pang inihahambing ang Google: ang pagkakakilanlang inaangkin ng kapares sa pagpapalitan ng IKE. Sa FortiGate, maaaring magpalit ng uri ang pagkakakilanlang iyon nang walang nag-e-edit ng address. Basahin ang log bilang hindi pagtutugma ng pagkakakilanlan kapag naipasok muli ang key nang dalawang beses.
Isang pagkabigo, dalawang pagsusuri
Sinusuri ng IKE ang isang kapares sa dalawang hiwalay na hakbang. Pinatutunayan ng paunang ibinahaging key na pareho ang sikreto ng dalawang dulo, at sinasabi ng inaangking pagkakakilanlan sa tumutugon kung sino ang sinasabi ng kapares na siya. Inihahambing ng Google ang pagkakakilanlang iyon sa kapares na kinaayunan nito. Kung pababayaan, nagpapadala ang FortiGate ng pagkakakilanlang nakabatay sa address na hinango sa palabas na interface nito, at pumapasa ang paghahambing nang walang makapansin.
Parehong napupunta sa iisang balde sa log ang dalawang hakbang, na nagpapaliwanag sa pamilyar na loop ng paulit-ulit na pag-type ng key nang apat na beses bago may bumasa ng payload ng pagkakakilanlan.
Ano ang inilalagay ng FortiGate sa payload ng pagkakakilanlan
Nagsisimula ang problema kapag may nagtatakda ng lokal na ID upang magkasundo ang dalawang panig. Minamarkahan ng mga bagong build ng FortiOS ang pagkakakilanlang iyon bilang ganap na kwalipikadong domain name kahit na ang halagang naipasok ay address na may tuldok. Kaya tumatanggap ang Google ng pagkakakilanlang FQDN habang umaasa ng address, at tinatanggihan nito ang session. Walang sinasabi ang mensahe kung aling kalahati ang nabigo, kaya binabasa ang ulat bilang kabiguan sa authentication.
Isang beses itong gawing muli nang bukas ang IKE debugging at basahin ang payload ng pagkakakilanlang aktuwal na ipinapadala ng firewall.
Sa parehong pagdaan, tiyakin ang tatlong murang katotohanan: ang bersyon ng IKE na ginagamit ng dalawang dulo, ang eksaktong key kasama ang mga di-nakikitang huling karakter, at ang address ng kapares na inaasahan ng Google. Iba-iba ang sinasagot nila, at ang tugmang key ay walang sinasabi tungkol sa pagkakakilanlan.
Mga opsyon, at ang halaga ng bawat isa
Bawat labasan ay nag-aayos ng ibang antas, at wala sa kanila ang magagamit sa lahat ng deployment.
| 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 |
Ang pagwawasto ng pagkakakilanlan sa firewall ang pinakamalinaw na sagot kung saan pinapayagan ka ng firmware na pumili ng uri at panatilihin ang halaga. Umiiral ang field sa ilang build at mali ang pagpuno ng uri sa iba, kaya subukan ang iyong bersyon sa halip na magtiwala sa release notes.
Ang address na pampubliko at naipapasa sa ruta sa interface ng negosasyon ang dokumentadong paraan ng pag-iwas, dahil tugma noon ang default na pagkakakilanlan sa inaasahan ng Google at walang kailangang override. Doon nagtatapos ang karamihan ng deployment, kung kaya man ng firewall na humawak ng ganoong address.
Ang pagtatapos sa isang kapares na nagbabalido sa ginagawa mo ay pagbabago ng topolohiya. Ituring ito bilang desisyon sa disenyo at hindi bilang paraan ng pag-iwas na may mas magiliw na paglalarawan.
Kapag tinanggal ng NAT ang isang opsyon
Sa likod ng NAT nawawala ang labasan sa pampublikong address, at ang natitira ay nakadepende sa pag-uugali ng firmware na hindi mo kontrolado. Ito ang puntong sadyang pumili sa pagitan ng pag-upgrade, paglipat ng kapares, o pagtanggap ng ibang cloud endpoint. Tatlong magkaibang badyet ito, at ang aksidenteng pagpili ng isa ang paraan ng pagkakataong nagiging arkitektura ang pansamantalang paraan ng pag-iwas. Isulat ang pinili at ang dahilan nito sa tabi ng tunnel.
Bago bigyang-kahulugan ang alinman dito, tiyakin ang kalagayan ng tunnel sa panig ng Google at na hindi lang basta itinatapon ang IKE sa daan. Ang itinapong packet ay nag-time out; hindi ito gumagawa ng pagtanggi.
Ano ang itatala habang gumagana ito
Itala ang uri ng pagkakakilanlan, ang halaga nito, ang bersyon ng firmware at ang address ng kapares na umiiral nang huling umangat ang tunnel. Maaaring baguhin muli ng update ng firmware ang default, at ang susunod na kabiguan ay magmumukhang eksaktong hindi pagtutugma ng key. Kapag nakatago ang pagkakakilanlan sa tabi ng key at ng address ng kapares, magsisimula ang susunod na tao sa mga murang pagsusuri.
Ang talaan ding iyon ang tanging paraan para malaman kung kailangan pa ang paraan ng pag-iwas pagkatapos ng susunod na upgrade.