Adăugarea unei subrețele locale la un AWS VPN: VGW sau Transit Gateway

Un VPN Site-to-Site existent transportă 10.60.0.0/16, o nouă rețea de servicii apare în spatele aceleiași porți locale ca 10.70.0.0/16, iar cineva întreabă dacă este nevoie de un proxy. De obicei nu: o cale rutată poate transporta prefixul, dar numai dacă trei lucruri se aliniază, iar care trei depinde de arhitectura AWS pe care o rulezi deja. O poartă privată virtuală are o singură limită de tabelă de rute; un transit gateway adaugă a doua. Anunțul corect cu tabela greșită produce o sesiune care pare sănătoasă și nu livrează nimic.

Publicați un prefix pe care poarta îl poate livra cu adevărat

Poarta locală are nevoie de o rută înainte către noua rețea înainte ca orice anunț să aibă sens. Anunțarea 10.70.0.0/16 prin BGP îi spune AWS unde să trimită pachetele pentru acel interval; nu creează calea locală de expediere care face intervalul accesibil la celălalt capăt. Confirmați că poarta are o rută pentru prefix care indică dispozitivul ce îl deține și că dispozitivul este configurat să răspundă pentru acele adrese. Politica de export și limitele de prefix acceptate sunt următoarea constrângere, deoarece un prefix pe care sesiunea îl filtrează nu ajunge deloc la AWS.

Păstrați agregatele și rutele mai specifice în mod deliberat. Căile suprapuse care vin din două direcții sunt o decizie de proiectare, nu un detaliu descoperit mai târziu.

Calea unu: limita porții private virtuale

Cu o poartă privată virtuală, documentația de rutare AWS VPN descrie două moduri de distribuție, rute statice și anunțuri BGP, iar ambele depind de tabela de rute a subrețelei pe care aplicația o folosește efectiv. Propagarea este comodă când controlați întregul interval, iar o rută explicită este mai ușor de argumentat când doriți destinația listată lângă țintă. În orice caz, verificarea este aceeași: tabela subrețelei aplicației specifice conține o cale funcțională către ținta VPN pentru noul prefix și câștigă împotriva a ceva mai specific?

O sesiune BGP sănătoasă dovedește că canalul există. Nu spune nimic despre dacă o anumită tabelă de subrețea a consumat ruta.

Calea doi: transit gateway adaugă o tabelă

Un transit gateway împarte acea singură întrebare în două. Subrețeaua VPC trebuie să trimită destinația către atașamentul transit gateway, iar apoi tabela de rute a transit gateway trebuie să selecteze atașamentul VPN pentru același prefix. Alegerile de asociere și propagare decid ce rețele atașate primesc ruta, așa că un prefix poate fi anunțat corect de VPN și totuși să nu ajungă niciodată la VPC a cărei tabelă nu a fost niciodată asociată cu tabela de rute corectă.

Defecțiunea obișnuită este o rută care există într-o tabelă și nu în cealaltă, fiecare echipă fiind convinsă că partea ei este corectă. Când comparați cele două arhitecturi, această limită suplimentară este toată diferența: mai multe locuri de verificat și un control mai precis asupra cine primește ruta.

Nici propagarea rutelor nu acordă prefixul fiecărui atașament. Îl distribuie către tabelele configurate să îl primească.

Calea de retur este o decizie de politică separată

Traficul care sosește este doar jumătate din schimb. Noua rețea locală are nevoie de o rută înapoi către prefixele sursă AWS prin poarta corectă, iar politica de securitate de la ambele capete trebuie să permită acea pereche sursă-destinație. Dacă tunelul negociază un domeniu de protecție cu selectoare de trafic, noul prefix trebuie să fie în interiorul lui, altfel pachetul este eliminat înainte de a fi consultată vreo tabelă de rute.

Suprapunerea adreselor este cealaltă capcană. Intervalele disjuncte, cu proprietate explicită, păstrează acest lucru simplu; intervalele suprapuse înseamnă traducere sau reproiectare, iar niciuna nu este o variantă interschimbabilă a aceleiași rețete.

Testați cu o sursă în noua rețea și o destinație în subrețeaua aplicației, apoi repetați în direcția opusă. Un test unidirecțional demonstrează doar o direcție.

Când proxy-ul este cu adevărat limita mai bună

Un proxy își câștigă locul când cerința este o interfață de serviciu îngustă, când aplicația așteaptă deja acea arhitectură sau când calea de rețea nu poate fi făcută să transporte prefixul fără o traducere pe care nu o doriți. Nu este soluția de rezervă pentru o intrare în tabela de rute pe care nimeni nu a verificat-o.

Decideți în această ordine: expediere locală, anunț, limita tabelului, politică de retur. Remediați prima care eșuează și abia apoi întrebați dacă calea rutată este răspunsul corect.