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

Objavite prefiks koji gateway zaista može dostaviti

Lokalnom gatewayju treba ruta prema novoj mreži prije nego bilo koji oglas ima smisla. Oglašavanje 10.70.0.0/16 kroz BGP govori AWS-u kuda slati pakete za taj raspon; ono ne stvara lokalnu putanju prosljeđ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 sljedeće ograničenje, jer prefiks koji sesija filtrira nikada ne stiže do AWS-a.

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

Putanja prva: granica virtuelnog privatnog gatewayja

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

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

Putanja druga: transit gateway dodaje tablicu

Transit gateway dijeli to jedno pitanje na dva. VPC podmreža mora poslati odredište na transit gateway attachment, a zatim transit gateway tablica ruta mora odabrati VPN attachment 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 tablica nikada nije bila povezana s pravom tablicom ruta.

Uobičajeni kvar je ruta koja postoji u jednoj tablici, a ne u drugoj, pri čemu je svaki tim uvjeren da je njegova strana ispravna. Kada uporedite dvije arhitekture, ta dodatna granica je cijela razlika: više mjesta za provjeru i preciznija kontrola nad tim ko dobija rutu.

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

Povratna putanja je zasebna politička odluka

Saobraćaj koji stigne samo je polovina razmjene. Nova lokalna mreža treba rutu natrag prema AWS izvornim prefiksima kroz ispravan gateway, a sigurnosna 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 prije nego što se pogleda bilo koja tablica ruta.

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

Testirajte s izvorom u novoj mreži i odredištem u aplikacijskoj podmreži, pa ponovite u suprotnom smjeru. Jednosmjerni test dokazuje samo jedan smjer.

Kada je proxy zaista bolja granica

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

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

Povezani članci