Voeg ’n plaaslike subnet by ’n AWS VPN: VGW teenoor Transit Gateway
’n BGP-aankondiging wys vir AWS waarheen om pakkette te stuur; dit skep nie ’n plaaslike pad nie. Kontroleer eers die VGW- of transit gateway-grens en dan die terugkeerbeleid.
’n Bestaande Site-to-Site VPN dra 10.60.0.0/16, ’n nuwe diensnetwerk verskyn agter dieselfde plaaslike gateway as 10.70.0.0/16, en iemand vra of ’n proxy nodig is. Gewoonlik is dit nie: ’n geroteerde pad kan die voorvoegsel dra, maar net as drie dinge in lyn kom, en watter drie hang af van die AWS-argitektuur wat jy reeds bedryf. ’n Virtuele privaat gateway het een roetetabelgrens; ’n transit gateway voeg ’n tweede by. Om die aankondiging reg en die tabel verkeerd te kry, lewer ’n sessie op wat gesond lyk en niks lewer nie.
Publiseer ’n voorvoegsel wat die gateway werklik kan aflewer
Die plaaslike gateway het ’n deurgaande roete na die nuwe netwerk nodig voordat enige aankondiging betekenis het. Om 10.70.0.0/16 deur BGP aan te kondig, sê vir AWS waarheen om pakkette vir daardie reeks te stuur; dit skep nie die plaaslike aanstuurpad wat die reeks aan die ander kant bereikbaar maak nie. Bevestig dat die gateway ’n roete vir die voorvoegsel het wat na die toestel wys wat dit hou, en dat die toestel opgestel is om vir daardie adresse te antwoord. Uitvoerbeleid en aanvaarde voorvoegsellimiete is die volgende beperking, want ’n voorvoegsel wat die sessie uitfilter, bereik AWS glad nie.
Hou samevattings en meer-spesifieke roetes doelbewus. Oorvleuelende paaie wat uit twee rigtings kom, is ’n ontwerpbesluit, nie ’n detail om later te ontdek nie.
Pad een: die grens van die virtuele privaat gateway
Met ’n virtuele privaat gateway beskryf die AWS VPN-roeteringsdokumentasie twee verspreidingsmodusse, statiese roetes en BGP-aankondigings, en albei hang af van die subnetroetetabel wat die toepassing werklik gebruik. Propagasie is gerieflik wanneer jy die hele reeks beheer, en ’n eksplisiete roete is makliker om te beredeneer wanneer jy die bestemming langs die teiken wil sien. In beide gevalle is die kontrole dieselfde: bevat die tabel van die spesifieke toepassingsubnet ’n werkende pad na die VPN-teiken vir die nuwe voorvoegsel, en wen dit teen enigiets meer spesifiek?
’n Gesonde BGP-sessie bewys die kanaal bestaan. Dit sê niks oor of ’n gegewe subnettabel die roete verbruik het nie.
Pad twee: die transit gateway voeg ’n tabel by
’n Transit gateway verdeel daardie een vraag in twee. Die VPC-subnet moet die bestemming na die transit gateway-aanhegting stuur, en dan moet die transit gateway-roetetabel die VPN-aanhegting vir dieselfde voorvoegsel kies. Assosiasie- en propagaisekeuses bepaal watter aangehegte netwerke die roete ontvang, so ’n voorvoegsel kan korrek deur die VPN aangekondig word en steeds nooit die VPC bereik waarvan die tabel nooit aan die regte roetetabel gekoppel is nie.
Die algemene fout is ’n roete wat in een tabel bestaan en nie in die ander nie, terwyl elke span oortuig is sy kant is korrek. Wanneer jy die twee argitekture vergelyk, is hierdie ekstra grens die hele verskil: meer plekke om te kyk, en meer presiese beheer oor wie die roete kry.
Roetepropagasie gee ook nie elke aanhegting die voorvoegsel nie. Dit versprei dit na die tabelle wat opgestel is om dit te ontvang.
Die terugkeerpad is sy eie beleidsbesluit
Verkeer wat aankom, is net die helfte van die uitruiling. Die nuwe plaaslike netwerk het ’n roete terug na die AWS-bronvoorvoegsels deur die korrekte gateway nodig, en die sekuriteitsbeleid aan beide kante moet daardie bron- en bestemmingspaar toelaat. As die tonnel ’n beskermingsomvang met verkeerskeiers beding, moet die nuwe voorvoegsel daarbinne wees, anders word die pakket laat val voordat enige roetetabel geraadpleeg word.
Adresoorvleueling is die ander lokval. Disjunkte, eksplisiet besitde reekse hou dit eenvoudig; oorvleuelende reekse beteken vertaling of ’n herontwerp, en nie een is ’n uitruilbare variant van dieselfde resep nie.
Toets met ’n bron in die nuwe netwerk en ’n bestemming in die toepassingsubnet, en herhaal dan in die ander rigting. ’n Eenrigtingtoets bewys net een rigting.
Wanneer die proxy werklik die beter grens is
’n Proxy verdien sy plek wanneer die vereiste ’n smal dienskoppelvlak is, wanneer die toepassing reeds daardie argitektuur verwag, of wanneer die netwerkpad nie die voorvoegsel kan dra sonder vertaling wat jy nie wil hê nie. Dit is nie die terugvalopsie vir ’n roetetabelinskrywing wat niemand nagegaan het nie.
Besluit in hierdie volgorde: plaaslike aanstuur, aankondiging, tabelgrens, terugkeerbeleid. Maak die eerste een reg wat faal, en vra eers daarna of die geroteerde pad hoegenaamd die regte antwoord is.