Ang cloud VPN ay nangangailangan ng BGP: bakit nabibigo ang ibang routing protocol

Nakaupo ang IPsec security association, gumagalaw ang mga counter ng tunnel, at naglalaho ang trapiko patungo sa cloud prefix. Sinusubukan ng operator na i-enable ang OSPF sa router ng customer, umaasa na mabubuo ang kapitbahay, at walang nangyayari. Ang tunnel ay hindi kailanman ang kulang na piraso: ang managed cloud VPN ay naglalabas ng tinukoy na routing contract, at sa malalaking platform ang kontratang iyon ay BGP. Hanggang may session at may tinatanggap na prefix, ang tunnel ay isang naka-encrypt na landas lamang na walang destinasyon sa likuran.

Nakaupo ang tunnel at nawawala ang ruta

Ang pagkumpleto ng phase 1 at phase 2 ay nagpapatunay na nagkasundo ang mga panig sa proteksyon, hindi na alam ng alinmang panig kung saan ipapadala ang trapiko. Ito ay magkahiwalay na state machine na may magkahiwalay na failure mode.

Magtanong ng tatlo sa pagkakasunod-sunod: inihayag ba ang prefix, tinanggap ba ito ng kapitbahay, at na-install ba ito para sa forwarding? Ang prefix na inihayag at sinuri ay problema sa patakaran. Ang prefix na hindi kailanman inihayag ay problema sa session o configuration. Ang prefix na tinanggap ngunit hindi na-install ay problema sa pagpili ng ruta, at bawat sagot ay tumuturo sa ibang bahagi ng configuration.

Ano ang talagang ibinibigay ng provider

Ang managed VPN gateway ay hindi walang limitasyong router. Binibigyan ka ng provider ng gateway na may sinusuportahang address ng kapitbahay, setting ng autonomous system, limitasyon ng prefix, at tinukoy na pag-uugali sa pagkabigo. Ang ibabaw na iyon ang produkto.

Dinodokumento ng Google Cloud ang dynamic na BGP routing para sa HA VPN, kung saan natututo ang Cloud Router ng mga ruta ng kapitbahay at nagbibigay ng karapat-dapat na custom na dynamic na ruta sa VPC. Dinodokumento ng AWS Site-to-Site VPN ang pagpili sa pagitan ng static at dynamic na routing, at inilalarawan ang BGP liveness check bilang kapaki-pakinabang para sa tunnel failover habang sinusuportahan din ang health check para sa mga device na walang BGP. Ang pag-uugali ng alinmang platform ay hindi dapat hinuha mula sa pangalan ng produkto ng isa.

Ang praktikal na kahihinatnan ay pinipili mo muna ang managed mode, pagkatapos ay binabasa ang mga sinusuportahang parameter. Ang disenyong nagpapalagay ng uri ng adjacency na hindi inaalok ng serbisyo ay hindi problema sa configuration na lutasin sa router ng customer.

Ang proteksyon ng tunnel at ang maabot ay magkahiwalay na gawain

Pinoprotektahan ng IPsec ang trapikong pinili para sa tunnel. Nagbibigay ang BGP ng impormasyon sa maabot na nagpapaging-karapat-dapat sa prefix. Ang gumaganang tunnel ay hindi nagpapatunay na ang inaasahang prefix ay inihayag, tinanggap, o na-install.

Isipin ang isang sangay na naghahayag ng 10.42.0.0/16 sa dalawang karapat-dapat na landas ng tunnel. Alisin ang isang magagamit na landas at maaaring magbago ang pagpili ng ruta nang walang nag-edit ng ruta ng bawat workload. Ang pagtuklas, pagpili ng ruta, at pagbawi ng application ay hindi agaran, at hindi magkapareho sa mga deployment, kaya ang failover test ay dapat magmasid sa buong pagkakasunod-sunod at hindi sa unang packet na makakalusot.

Kapag hindi maabot ang cloud prefix, tingnan ang estado ng session at ang mga natutunang ruta bago hawakan ang cryptography. Ang nakaupong SA na walang ruta sa likuran ay ang pinakakaraniwang anyo ng sintomas na ito.

Saan nababasag ang mga pagpapalagay tungkol sa OSPF

Ang OSPF, IS-IS o ibang protocol sa loob ng IPsec tunnel ay lubos na posible sa isang self-managed appliance, kung saan pagmamay-ari mo ang dalawang dulo at ang disenyo ng forwarding. Ang katotohanang iyon ay walang sinasabi tungkol sa isang managed na serbisyo na BGP lamang ang inaalok bilang dynamic na routing mode.

Kung ang iminungkahing disenyo ay nangangailangan ng adjacency na hindi sinusuportahan ng serbisyo, sadyang baguhin ang arkitektura. Kasama sa mga opsyon ang self-managed appliance sa VPC, static na routing kung saan sinusuportahan ito ng serbisyo, o ibang produkto ng konektibidad. Ang pag-configure ng protocol sa router ng customer lamang ay hindi makakadagdag ng kapitbahay sa panig ng cloud na wala, at hindi nito gagawing lumitaw ang prefix.

Huwag ilipat ang sagot ng isang vendor sa gateway ng iba. Ang parehong mga salita, tulad ng dynamic na routing o tunnel failover, ay maaaring maglarawan ng iba't ibang mekanismo at iba't ibang limitasyon.

Basahin ang pangangailangan ng serbisyo, pagkatapos ay magdisenyo

Bago ang unang linya ng configuration, isulat ang mga address ng kapitbahay, ang mga numero ng autonomous system, ang mga prefix na ihahayag at tatanggapin mo, ang mga limitasyon ng ruta, at ang inaasahang pag-uugali kapag nabigo ang tunnel. Ang limang item na iyon ang kontratang disenyo mo.

Pagkatapos ay i-verify sa parehong pagkakasunod-sunod: naitatag ang session, natanggap ang prefix, naroroon ang ruta sa talahanayan ng ruta ng VPC, at may tunay na daloy patungo sa isang address ng serbisyo. Ulitin pagkatapos ng sapilitang failover, dahil ang session na muling naitatag ay maaaring bumalik na may ibang set ng ruta. Kung ang disenyo ay umaasa sa convergence na wala pang isang segundo, sukatin ito sa halip na ipagpalagay.

Itago ang kontrata ng serbisyo kasama ng talaan ng pagbabago. Kapag may nagtanong mamaya kung bakit hindi mapatakbo ng tunnel ang OSPF, ang sagot ay hangganan ng produkto, hindi limitasyon ng protocol, at dapat sabihin iyon ng talaan.