Mai multe LAN-uri pe un singur tunel VPN AWS: ce înseamnă limita SA
AWS permite o pereche IPsec SA pe tunel, iar aceasta nu este o limită de o singură subrețea. Separați mai întâi domeniul de protecție de rutare și de acces.
Adăugarea unei a doua LAN de sucursală la un AWS Site-to-Site VPN nu necesită o a doua asociere IPsec independentă în acel tunel. Limita de care oamenii se împiedică este reală, dar mai îngustă decât sună: AWS documentează o pereche IPsec SA unică pe tunel, una de intrare și una de ieșire, iar cele două tuneluri dintr-o conexiune primesc fiecare propria pereche. Aceasta este o proprietate a serviciului, nu o regulă că IPsec protejează o singură subrețea odată. Distincția contează cel mai mult când un gateway de client bazat pe politici transformă fiecare intrare de politică în propria asociere.
Începeți cu conexiunea, nu cu lista de LAN-uri
Deschideți conexiunea în consolă și observați cum este rutată. O conexiune statică transportă prefixele la distanță pe care le-ați declarat. O conexiune BGP le învață de la gateway-ul de client.
În orice caz, tunelul se bazează pe rute. Ce intră în el este decis de selectorii pe care dispozitivul îi negociază, nu de numărul de subrețele pe care le puteți tasta într-un formular.
Urmăriți ce negociază gateway-ul de client
Un dispozitiv bazat pe politici poate transforma fiecare intrare de politică în propriul SA. Două LAN-uri înseamnă două intrări, ceea ce înseamnă două SA, și aici limita pe tunel începe să conteze. Cerințele gateway-ului de client avertizează exact despre acest comportament și sugerează reguli consolidate pe acele dispozitive. Verificați selectorii negociați, nu numărul de ACL-uri de pe dispozitiv.
Dispozitivul trebuie configurat să prezinte ambele prefixe sub o singură politică, altfel capătul îndepărtat pur și simplu nu poate ține rezultatul.
Trei inventare, ținute separat
Amestecați aceste trei liste și fiecare modificare devine o presupunere. Țineți-le ca coloane separate și completați fiecare pentru propria rețea.
| Inventory | What belongs there |
|---|---|
| Required networks | 10.20.10.0/24 and 10.20.30.0/24, as presented after any deliberate translation |
| Protection agreement | the selectors the tunnel actually negotiated for those prefixes |
| Delivery and permission | VPC routes, return routes, security groups and any filtering |
Doar coloana din mijloc este constrânsă de limita SA. Prima coloană este un fapt de afaceri, iar a treia este ceea ce face o aplicație să funcționeze. Citiți selectorii acceptați pe dispozitiv în loc să deduceți acoperirea din numărul de linii ACL pe care le-ați scris.
Consolidați fără a lărgi permisiunea
O rută sumarizată este modalitatea evidentă de a obține o singură intrare de politică și este și modul în care un set protejat crește în liniște. Un /20 care acoperă ambele /24 acoperă și adrese pe care niciuna dintre sucursale nu le folosește, iar tunelul le va transporta bucuros. Dacă trebuie să sumarizați, asociați-l cu filtrarea pe partea receptoare, astfel încât spațiul suplimentar să fie refuzat, nu doar neanunțat. Un pachet refuzat este o dovadă. O adresă neanunțată este doar o absență a dovezii.
Consolidarea politicii de protecție este o schimbare a ceea ce poate fi criptat. Nu este o acordare de acces și nu ar trebui tratată ca atare.
Testați ambele LAN-uri, apoi păstrați ambele tuneluri
După o modificare coordonată, inspectați domeniul de protecție activ și apoi executați o aplicație reală din fiecare LAN. Faptul că o subrețea funcționează nu dovedește nimic despre acoperirea selectorilor celeilalte și cu atât mai puțin despre calea sa de răspuns.
Păstrați ambele tuneluri în proiect. Consolidarea politicii nu este permisiunea de a renunța la redundanță, iar un singur tunel care transportă fiecare LAN de sucursală transformă următoarea fereastră de mentenanță într-o întrerupere.
Scrieți selectorii negociați, cele două prefixe și proprietarii rutelor în același registru de modificări. Când apare o a treia LAN, acel registru vă spune dacă adăugați un selector sau o luați de la capăt.