Dodajte lokalnu podmrežu na AWS VPN: VGW nasuprot Transit Gateway

Postojeći Site-to-Site VPN prenosi 10.60.0.0/16, iza istog lokalnog gatewaya pojavljuje se nova servisna mreža kao 10.70.0.0/16, i neko pita da li je potreban proxy. Obično nije: rutirana putanja može preneti prefiks, ali samo ako se poklope tri stvari, a koje tri zavisi od AWS arhitekture koju već vodite. Virtuelni privatni gateway ima jednu granicu tabele ruta; transit gateway dodaje drugu. Ispravan oglas uz pogrešnu tabelu daje sesiju koja izgleda zdravo i ne dostavlja ništa.

Objavite prefiks koji gateway zaista može da dostavi

Lokalnom gatewayu treba ruta prema novoj mreži pre nego što bilo koji oglas ima smisla. Oglašavanje 10.70.0.0/16 kroz BGP govori AWS-u gde da šalje pakete za taj raspon; ono ne stvara lokalnu putanju prosleđivanja koja raspon čini dostupnim na drugom kraju. Potvrdite da gateway ima rutu za prefiks koja pokazuje na uređaj koji ga drži i da je uređaj konfigurisan da odgovara na te adrese. Izvozna politika i prihvaćeni limiti prefiksa su sledeće ograničenje, jer prefiks koji sesija filtrira nikada ne stiže do AWS-a.

Neka agregati i specifičnije rute budu namerni. Putanje koje se preklapaju i dolaze iz dva smera su dizajnerska odluka, a ne detalj koji se otkriva kasnije.

Putanja prva: granica virtuelnog privatnog gatewaya

Uz virtuelni privatni gateway, AWS VPN dokumentacija za rutiranje opisuje dva načina distribucije — statične rute i BGP oglase — a oba zavise od tabele ruta podmreže koju aplikacija zaista koristi. Propagacija je zgodna kada kontrolišete ceo raspon, a eksplicitna ruta se lakše promišlja kada želite odredište navedeno uz cilj. U oba slučaja provera je ista: sadrži li tabela konkretne aplikacijske podmreže radnu putanju do VPN cilja za novi prefiks i pobeđuje li protiv nečeg specifičnijeg?

Zdrava BGP sesija dokazuje da kanal postoji. Ne govori ništa o tome da li je određena tabela podmreže preuzela rutu.

Putanja druga: transit gateway dodaje tabelu

Transit gateway deli to jedno pitanje na dva. VPC podmreža mora da pošalje odredište na transit gateway prilog, a zatim transit gateway tabela ruta mora da odabere VPN prilog za isti prefiks. Izbori asocijacije i propagacije odlučuju koje priključene mreže dobijaju rutu, pa prefiks može biti ispravno oglašen kroz VPN i ipak nikada ne stigne do VPC-a čija tabela nikada nije bila povezana s pravom tabelom ruta.

Uobičajeni kvar je ruta koja postoji u jednoj tabeli, a ne u drugoj, pri čemu je svaki tim uveren da je njegova strana ispravna. Kada uporedite dve arhitekture, ta dodatna granica je cela razlika: više mesta za proveru i preciznija kontrola nad tim ko dobija rutu.

Propagacija ruta takođe ne daje prefiks svakom prilogu. Ona ga distribuira tabelama konfigurisanim da ga primaju.

Povratna putanja je zasebna politička odluka

Saobraćaj koji stigne samo je polovina razmene. Nova lokalna mreža treba rutu nazad prema AWS izvornim prefiksima kroz ispravan gateway, a bezbednosna politika na oba kraja mora dopustiti taj par izvora i odredišta. Ako tunel pregovara obim zaštite sa selektorima saobraćaja, novi prefiks mora biti unutar njega, inače se paket odbacuje pre nego što se pogleda bilo koja tabela ruta.

Preklapanje adresa je druga zamka. Nepreklapajući, izričito posedovani rasponi drže ovo jednostavnim; rasponi koji se preklapaju znače prevođenje ili redizajn, a nijedno nije zamenljiva varijanta istog recepta.

Testirajte sa izvorom u novoj mreži i odredištem u aplikacijskoj podmreži, pa ponovite u suprotnom smeru. Jednosmerni test dokazuje samo jedan smer.

Kada je proxy zaista bolja granica

Proxy zaslužuje svoje mesto kada je zahtev uzak servisni interfejs, kada aplikacija već očekuje tu arhitekturu ili kada se mrežna putanja ne može naterati da prenosi prefiks bez prevođenja koje ne želite. On nije rezervno rešenje za unos u tabeli ruta koji niko nije proverio.

Odlučite ovim redom: lokalno prosleđivanje, oglas, granica tabele, politika povratka. Popravite prvo koje padne i tek onda pitajte da li je rutirana putanja uopšte pravi odgovor.