Lisää paikallinen aliverkko AWS VPN:ään: VGW vai Transit Gateway
BGP-ilmoitus kertoo AWS:lle, minne paketit lähetetään; se ei luo paikallista reittiä. Tarkista VGW:n tai transit gatewayn raja ja sitten paluupolitiikka.
Olemassa oleva Site-to-Site VPN kuljettaa osoitetta 10.60.0.0/16, saman paikallisen yhdyskäytävän taakse ilmestyy uusi palveluverkko osoitteena 10.70.0.0/16, ja joku kysyy, tarvitaanko välityspalvelinta. Yleensä ei: reititetty polku voi kuljettaa etuliitteen, mutta vain jos kolme asiaa osuu kohdalleen, ja mitkä kolme, riippuu siitä AWS-arkkitehtuurista, jota jo ajat. Virtuaalisella yksityisellä yhdyskäytävällä on yksi reititystaulun raja; transit gateway lisää toisen. Oikea ilmoitus ja väärä taulu tuottavat istunnon, joka näyttää terveeltä eikä toimita mitään.
Julkaise etuliite, jonka yhdyskäytävä voi todella toimittaa
Paikallinen yhdyskäytävä tarvitsee eteenpäin vievän reitin uuteen verkkoon ennen kuin mikään ilmoitus on mielekäs. 10.70.0.0/16:n ilmoittaminen BGP:n kautta kertoo AWS:lle, minne kyseisen alueen paketit lähetetään; se ei luo paikallista välityspolkua, joka tekee alueesta tavoitettavan toisessa päässä. Varmista, että yhdyskäytävällä on etuliitteelle reitti, joka osoittaa sitä pitävään laitteeseen, ja että laite on määritetty vastaamaan noista osoitteista. Vientikäytäntö ja hyväksytyt etuliiterajat ovat seuraava rajoite, koska etuliite, jonka istunto suodattaa pois, ei koskaan saavu AWS:ään.
Pidä koosteet ja tarkemmat reitit tarkoituksellisina. Kahdesta suunnasta tulevat päällekkäiset polut ovat suunnittelupäätös, eivät myöhemmin löydettävä yksityiskohta.
Polku yksi: virtuaalisen yksityisen yhdyskäytävän raja
Virtuaalisella yksityisellä yhdyskäytävällä AWS VPN:n reititysdokumentaatio kuvaa kaksi jakelutilaa, staattiset reitit ja BGP-ilmoitukset, ja molemmat riippuvat aliverkon reititystaulusta, jota sovellus todella käyttää. Propagointi on kätevää, kun hallitset koko aluetta, ja eksplisiittinen reitti on helpompi perustella, kun haluat kohteen lueteltuna tavoitteen viereen. Kummassakin tapauksessa tarkistus on sama: sisältääkö kyseisen sovelluksen aliverkon taulu toimivan polun VPN-tavoitteeseen uudelle etuliitteelle, ja voittaako se jotain tarkempaa vastaan?
Terve BGP-istunto todistaa, että kanava on olemassa. Se ei kerro, onko tietty aliverkkotaulu ottanut reitin käyttöön.
Polku kaksi: transit gateway lisää taulun
Transit gateway jakaa yhden kysymyksen kahdeksi. VPC-aliverkon on lähetettävä kohde transit gateway -liitännälle, ja sitten transit gatewayn reititystaulun on valittava VPN-liitäntä samalle etuliitteelle. Liittämis- ja propagointivalinnat ratkaisevat, mitkä liitetyt verkot saavat reitin, joten etuliite voidaan ilmoittaa VPN:stä oikein ja silti se ei koskaan saavu siihen VPC:hen, jonka taulua ei koskaan liitetty oikeaan reititystauluun.
Yleinen vika on reitti, joka on yhdessä taulussa eikä toisessa, ja jokainen tiimi on vakuuttunut oman puolensa oikeellisuudesta. Kun vertaat kahta arkkitehtuuria, tämä ylimääräinen raja on koko ero: enemmän paikkoja katsoa ja tarkempi hallinta siitä, kuka reitin saa.
Reittien propagointikaan ei anna etuliitettä jokaiselle liitännälle. Se jakaa sen tauluihin, jotka on määritetty vastaanottamaan sen.
Paluupolku on oma käytäntöpäätöksensä
Saapuva liikenne on vain puolet vaihdosta. Uusi paikallinen verkko tarvitsee paluureitin AWS:n lähde-etuliitteisiin oikean yhdyskäytävän kautta, ja molempien päiden tietoturvakäytännön on sallittava tuo lähde-kohde-pari. Jos tunneli neuvottelee suojausalueen liikenteen valitsimilla, uuden etuliitteen on oltava sen sisällä, tai paketti hylätään ennen kuin mitään reititystaulua tutkitaan.
Osoitteiden päällekkäisyys on toinen ansa. Erilliset, selkeästi omistetut alueet pitävät tämän yksinkertaisena; päällekkäiset alueet tarkoittavat käännöstä tai uudelleensuunnittelua, eikä kumpikaan ole saman reseptin vaihdettava muunnelma.
Testaa lähteellä uudessa verkossa ja kohteella sovelluksen aliverkossa ja toista sitten toiseen suuntaan. Yksisuuntainen testi todistaa yhden suunnan.
Kun välityspalvelin on todella parempi raja
Välityspalvelin ansaitsee paikkansa, kun vaatimuksena on kapea palvelurajapinta, kun sovellus jo odottaa sitä arkkitehtuuria, tai kun verkkopolkua ei saada kuljettamaan etuliitettä ilman käännöstä, jota et halua. Se ei ole vararatkaisu reititystaulun merkinnälle, jota kukaan ei tarkistanut.
Päätä tässä järjestyksessä: paikallinen välitys, ilmoitus, taulun raja, paluupolitiikka. Korjaa ensimmäinen, joka pettää, ja kysy vasta sitten, onko reititetty polku ylipäätään oikea vastaus.