GCP BYOIP: offentlig annoncering er ikke en privat rute
At dele et BYOIP-præfiks mellem lokation og cloud kræver to planer. Adskil den offentlige annoncering, uddelegeringen og det private næste hop.
En del af en offentlig blok bliver på lokationen, og en del flytter ind i Google Cloud. Den sætning beskriver to planer, ikke én: en internetannonceringsplan og en privat videresendelsesplan. At behandle dem som ét enkelt routingproblem er der, hvor BYOIP-design går galt.
De involverede objekter besvarer forskellige spørgsmål, og kun ét af dem handler om, hvor pakkerne går hen næste gang.
Tre objekter, tre spørgsmål
Et offentligt annonceret præfiks er den enhed, som Google annoncerer til internettet på dine vegne. Et offentligt delegeret præfiks er, hvordan importeret plads tildeles understøttede Cloud-ressourcer. En VPC-rute, herunder en der læres via Cloud Router fra en VPN, vælger et privat næste hop. Hver har sit eget omfang, sin egen API og sin egen fejlmeddelelse.
Tabelversionen er kortere.
| Object | Question it answers |
|---|---|
| Public advertised prefix | Which authorized range Google announces publicly |
| Public delegated prefix | How imported space is allocated to Cloud resources |
| VPN or Cloud Router route | Which private next hop carries a destination |
Kun den tredje række handler om videresendelse inde i dit netværk.
Hvad BYOIP-overlapadvarslen dækker
Googles BYOIP-dokumentation behandler det annoncerede præfiks som en annonceringsenhed og advarer om overlappende eksterne annonceringer, herunder et subpræfiks annonceret uden for Google. Den advarsel handler om den offentlige annonceringsplan. Den er ikke en udtalelse om enhver privat rute, du måtte tilføje.
At uddelegere en mindre tildeling inde i et importeret præfiks giver dig ikke i sig selv tilladelse til at annoncere resten fra en anden oprindelse.
Stil spørgsmålet i forhold til, hvem der annoncerer hvad. Hvis Google annoncerer hele det importerede præfiks, skaber en anden oprindelse, der annoncerer et subpræfiks, præcis det overlap, som dokumentationen advarer om, uanset hvor pæne dine VPC-ruter ser ud.
Hvad en privat rute afgør
Et præfiks, der læres via en VPN, er ikke en internetannoncering, og ingen mængde BGP vil gøre det til en. Det er en post i en VPC-rutetabel, der siger, hvilken tunnel eller gateway der skal bære trafik for den destination. Om posten er kvalificeret, valgt eller brugbar afhænger af VPC’ens egne ruteningsregler.
Længste præfiks-match gælder inde i rutetabellen, så en længere VPN-rute kan vinde lokalt uden at ændre noget ved den offentlige kant.
At dele et præfiks: beslutningen der kommer først
Hvis arkitekturen kræver, at halvdelen af blokken annonceres fra et datacenter og halvdelen fra Google, skal du afgøre annonceringsplanen, før du importerer noget. Bekræft, hvilke områder Google må annoncere, hvilke der forbliver annonceret andre steder, og om de to overlapper. Design derefter den private vej for hver destination og dens returvej. Hvis udbyderne ikke understøtter den opdeling, du ønsker, skal du ændre opdelingen i stedet for at håbe på, at et længere VPN-præfiks tilsidesætter en beslutning ved den offentlige kant.
Den rækkefølge betyder noget, fordi den anden plan ikke kan reparere den første.
Verificer begge planer separat
Kontroller den offentlige side med gcloud compute public-advertised-prefixes list og bekræft områderne og deres status. Kontroller den private side med gcloud compute routes list og gcloud compute routers get-status, som viser, hvad BGP faktisk udvekslede.
Ét sæt output fortæller dig, hvad internettet ser. Det andet fortæller dig, hvor din trafik går hen. Ingen af dem erstatter den anden.