Legg til et lokalt subnett i en AWS VPN: VGW kontra Transit Gateway

En eksisterende Site-to-Site VPN fører 10.60.0.0/16, et nytt tjenestenettverk dukker opp bak samme lokale gateway som 10.70.0.0/16, og noen spør om det trengs en proxy. Som regel ikke: en rutet vei kan føre prefikset, men bare hvis tre ting stemmer, og hvilke tre avhenger av AWS-arkitekturen du allerede kjører. En virtuell privat gateway har én rutetabellgrense; en transit gateway legger til en andre. Riktig annonsering og feil tabell gir en sesjon som ser sunn ut og ikke leverer noe.

Annonser et prefiks gatewayen faktisk kan levere

Den lokale gatewayen trenger en videre vei til det nye nettet før noen annonsering gir mening. Å annonsere 10.70.0.0/16 via BGP forteller AWS hvor pakker for det området skal sendes; det oppretter ikke den lokale videresendingsveien som gjør området tilgjengelig i den andre enden. Bekreft at gatewayen har en rute for prefikset som peker på enheten som holder det, og at enheten er konfigurert til å svare for disse adressene. Eksportpolitikk og aksepterte prefiksgrenser er den neste begrensningen, for et prefiks som sesjonen filtrerer bort når aldri frem til AWS.

Hold aggregater og mer spesifikke ruter bevisste. Overlappende veier som kommer fra to retninger er en designbeslutning, ikke en detalj man oppdager senere.

Vei én: grensen for den virtuelle private gatewayen

Med en virtuell privat gateway beskriver AWS VPN-dokumentasjonen for ruting to distribusjonsmoduser, statiske ruter og BGP-annonseringer, og begge avhenger av subnett-rutetabellen som applikasjonen faktisk bruker. Propagering er praktisk når du kontrollerer hele området, og en eksplisitt rute er lettere å resonnere om når du vil ha destinasjonen oppført ved siden av målet. Uansett er kontrollen den samme: inneholder tabellen for det konkrete applikasjonssubnettet en fungerende vei til VPN-målet for det nye prefikset, og vinner den over noe mer spesifikt?

En sunn BGP-sesjon beviser at kanalen finnes. Den sier ingenting om hvorvidt en gitt subnettabell har tatt opp ruten.

Vei to: transit gateway legger til en tabell

En transit gateway deler det ene spørsmålet i to. VPC-subnettet må sende destinasjonen til transit gateway-tilknytningen, og deretter må transit gateway-rutetabellen velge VPN-tilknytningen for samme prefiks. Valgene for tilknytning og propagering avgjør hvilke tilknyttede nett som mottar ruten, så et prefiks kan annonseres riktig av VPN-en og likevel aldri nå VPC-en der tabellen aldri ble knyttet til den riktige rutetabellen.

Den vanlige feilen er en rute som finnes i den ene tabellen og ikke i den andre, der hvert team er overbevist om at deres side er riktig. Når du sammenligner de to arkitekturene, er denne ekstra grensen hele forskjellen: flere steder å se etter, og mer presis kontroll over hvem som får ruten.

Rutepropagering gir heller ikke hver tilknytning prefikset. Den fordeler det til tabellene som er konfigurert til å motta det.

Returveien er sin egen politikkbeslutning

Trafikk som ankommer er bare halvparten av utvekslingen. Det nye lokale nettet trenger en rute tilbake til AWS-kildeprefiksene gjennom riktig gateway, og sikkerhetspolitikken i begge ender må tillate det paret av kilde og destinasjon. Hvis tunnelen forhandler om et beskyttelsesområde med trafikkvelgere, må det nye prefikset ligge innenfor, ellers blir pakken forkastet før noen rutetabell konsulteres.

Adresseoverlapp er den andre fellen. Atskilte, eksplisitt eide områder holder dette enkelt; overlappende områder betyr oversettelse eller en ny design, og ingen av dem er en utskiftbar variant av den samme oppskriften.

Test med en kilde i det nye nettet og en destinasjon i applikasjonssubnettet, og gjenta deretter i den andre retningen. En enveistest beviser bare én retning.

Når proxyen virkelig er den bedre grensen

En proxy fortjener plassen sin når kravet er et smalt tjenestegrensesnitt, når applikasjonen allerede forventer den arkitekturen, eller når nettveien ikke kan fås til å føre prefikset uten en oversettelse du ikke vil ha. Den er ikke reservevalget for en rutetabelloppføring som ingen har kontrollert.

Bestem i denne rekkefølgen: lokal videresending, annonsering, tabellgrense, returpolitikk. Rette opp den første som feiler, og spør først da om den rutete veien i det hele tatt er det riktige svaret.