Două locații, o subrețea: construiți o vizualizare de alias pentru fiecare

Două locații de client rulează ambele 192.168.50.0/24, iar un inginer la distanță trebuie să ajungă la o imprimantă la aceeași adresă în fiecare. Niciun truc de rutare nu rezolvă această ambiguitate de unul singur. Fiecare locație are nevoie de o vizualizare distinctă a adreselor, iar gateway-ul trebuie să aleagă locația din acea vizualizare înainte de a transmite ceva.

Planul are patru părți: prefixe de alias, ambele direcții de traducere, politica de suprapunere și nume. Fiecare trebuie să se acorde cu celelalte.

Alegeți un prefix de alias pe locație

Atribuiți fiecărei locații un prefix de alias întreg care nu aparține nimănui altcuiva din mediu. Un plan pentru două locații poate mapa 192.168.50.0/24 a locației A la 172.21.10.0/24 și LAN-ul identic al locației B la 172.21.20.0/24. Verificați candidații față de fiecare rețea participantă, inclusiv VPC din cloud și alte grupuri VPN. Spațiul de adrese private este partajat de fiecare organizație, așa că faptul că un interval este RFC 1918 nu spune nimic despre disponibilitatea lui aici.

Publicați aliasul, nu subrețeaua nativă, utilizatorilor la distanță. Intervalul nativ rămâne un fapt local.

Traduceți în ambele direcții

Traduceți în ambele direcții. Maparea destinației rescrie o adresă de alias în adresa nativă la locația care o deține. Maparea sursei rescrie apelantul la distanță într-un alias pe care celelalte locații îl pot distinge.

O mapare statică unu-la-unu este deterministă, iar asta nu face implementarea fără stare. Traducerea inversă poate depinde de starea conexiunii, iar comutarea la rezervă sau căile asimetrice pot rupe un plan care ignoră acest lucru. Documentația platformei decide care dintre aceste cazuri se aplică.

Etapa exactă în care se aplică politica, selectorii și rutele diferă între IPsec bazat pe politici, tuneluri bazate pe rute și alte produse. Proiectați pentru cel pe care îl rulați.

Duceți planul prin suprapunere

Într-un hub, atribuiți fiecare prefix de alias căii locației care îl deține și permiteți doar tranzitul de care are nevoie sarcina. Într-o plasă, fiecare partener relevant are nevoie de același prefix și de cunoștințe despre politică. Adăugarea de tuneluri nu repară adresarea ambiguă de una singură.

Publicarea întregii subrețele este mai largă decât publicarea unui singur serviciu. Dacă sunt necesare doar câteva mașini sau porturi, păstrați regulile de acces mai înguste decât maparea.

Traducerea antetelor nu rescrie încărcăturile aplicației. Redirecționările, adresele încorporate în fișierele de configurare și permisiunile bazate pe sursă pot transporta în continuare adresa nativă. Testați calea aplicației, nu doar ping. Un răspuns ICMP funcțional demonstrează că maparea există și nu spune nimic despre dacă aplicația acceptă aliasul.

Corectați numele pe care le vede fiecare apelant

Dați numelor de mentenanță răspunsuri care corespund vizualizării apelantului. Dacă inginerul la distanță rezolvă un nume de gazdă, ar trebui să returneze adresa de alias pentru acea locație, nu intervalul nativ partajat.

Verificați vizualizările DNS pe locație înainte de prima fereastră de mentenanță. Un nume care se rezolvă la subrețeaua nativă trimite apelantul înapoi în ambiguitatea pe care planul trebuia să o elimine.

Înregistrați și verificați pe locație

Acceptați fiecare locație separat de la un apelant real și confirmați ce mașină a răspuns. Înregistrați împreună adresa nativă, aliasul, gateway-ul proprietar și serviciul permis.

Acest inventar este cel care păstrează distincția când sosește o a treia locație cu aceeași LAN implicită. Ghidul IPsec NAT bazat pe politici documentează un model concret de traducere; nu este un contract pentru fiecare platformă.