En eksisterende Site-to-Site VPN transporterer 10.60.0.0/16, et nyt servicenetværk dukker op bag den samme lokale gateway som 10.70.0.0/16, og nogen spørger, om der kræves en proxy. Som regel ikke: en rutet vej kan transportere præfikset, men kun hvis tre ting passer sammen, og hvilke tre afhænger af den AWS-arkitektur, du allerede kører. En virtuel privat gateway har én rutetabelgrænse; en transit gateway tilføjer en anden. Rigtig annoncering og forkert tabel giver en session, der ser sund ud og ikke leverer noget.

Annoncér et præfiks, som gatewayen faktisk kan levere

Den lokale gateway skal have en videre vej til det nye netværk, før nogen annoncering giver mening. Annoncering af 10.70.0.0/16 via BGP fortæller AWS, hvor pakker til dette interval skal sendes hen; den opretter ikke den lokale videresendelsesvej, der gør intervallet tilgængeligt i den anden ende. Bekræft, at gatewayen har en rute til præfikset, der peger på den enhed, som holder det, og at enheden er konfigureret til at svare på disse adresser. Eksportpolitik og accepterede præfiksgrænser er den næste begrænsning, for et præfiks, som sessionen filtrerer fra, når slet ikke til AWS.

Hold aggregater og mere specifikke ruter bevidste. Overlappende veje, der kommer fra to retninger, er en designbeslutning, ikke en detalje, man opdager senere.

Vej et: grænsen for den virtuelle private gateway

Med en virtuel privat gateway beskriver AWS VPN-dokumentationen for routing to distributionstilstande, statiske ruter og BGP-annonceringer, og begge afhænger af den subnet-rutetabel, som applikationen faktisk bruger. Propagering er praktisk, når du kontrollerer hele intervallet, og en eksplicit rute er lettere at ræsonnere om, når du vil have destinationen opført ved siden af målet. Uanset hvad er kontrollen den samme: indeholder tabellen for det konkrete applikationssubnet en fungerende vej til VPN-målet for det nye præfiks, og vinder den over noget mere specifikt?

En sund BGP-session beviser, at kanalen findes. Den siger intet om, hvorvidt en given subnettabel har overtaget ruten.

Vej to: transit gateway tilføjer en tabel

En transit gateway deler det ene spørgsmål i to. VPC-subnettet skal sende destinationen til transit gateway-tilknytningen, og derefter skal transit gateway-rutetabellen vælge VPN-tilknytningen for samme præfiks. Valg af tilknytning og propagering afgør, hvilke tilknyttede netværk der modtager ruten, så et præfiks kan annonceres korrekt af VPN'en og alligevel aldrig nå den VPC, hvis tabel aldrig blev knyttet til den rigtige rutetabel.

Den almindelige fejl er en rute, der findes i den ene tabel og ikke i den anden, hvor hvert team er overbevist om, at dets side er korrekt. Når du sammenligner de to arkitekturer, er denne ekstra grænse hele forskellen: flere steder at kigge og mere præcis kontrol over, hvem der får ruten.

Rutepropagering giver heller ikke hver tilknytning præfikset. Den fordeler det til de tabeller, der er konfigureret til at modtage det.

Returvejen er sin egen politikbeslutning

Trafik, der ankommer, er kun halvdelen af udvekslingen. Det nye lokale netværk skal have en rute tilbage til AWS-kildepræfikserne gennem den korrekte gateway, og sikkerhedspolitikken i begge ender skal tillade det kilde- og destinationspar. Hvis tunnelen forhandler et beskyttelsesomfang med trafikvælgere, skal det nye præfiks ligge inden for det, ellers kasseres pakken, før nogen rutetabel konsulteres.

Adresseoverlap er den anden fælde. Adskilte, eksplicit ejede intervaller holder det enkelt; overlappende intervaller betyder oversættelse eller et redesign, og ingen af dem er en udskiftelig variant af den samme opskrift.

Test med en kilde i det nye netværk og en destination i applikationssubnettet, og gentag derefter i den anden retning. En envejstest beviser kun én retning.

Når proxyen virkelig er den bedre grænse

En proxy fortjener sin plads, når kravet er en smal servicegrænseflade, når applikationen allerede forventer den arkitektur, eller når netværksvejen ikke kan fås til at transportere præfikset uden en oversættelse, du ikke ønsker. Den er ikke reservevalget for en rutetabelpost, som ingen har kontrolleret.

Beslut i denne rækkefølge: lokal videresendelse, annoncering, tabelgrænse, returpolitik. Ret det første, der fejler, og spørg først derefter, om den rutede vej overhovedet er det rigtige svar.

Relaterede artikler