Dve lokality, jedna podsiete: pre každú vytvorte samostatný pohľad aliasov

Dve klientske lokality obe používajú 192.168.50.0/24 a vzdialený inžinier sa musí v každej dostať k tlačiarni na rovnakej adrese. Žiadny trik smerovania túto nejednoznačnosť sám nevyrieši. Každá lokalita potrebuje odlišný pohľad na adresy a brána musí vybrať lokalitu z tohto pohľadu predtým, ako čokoľvek prepošle.

Plán má štyri časti: prefixy aliasov, oba smery prekladu, politiku prekrytia a názvy. Každá sa musí zhodovať s ostatnými.

Vyberte jeden prefix aliasu na lokalitu

Každé lokalite priraďte celý prefix aliasu, ktorý v prostredí nepatrí nikomu inému. Plán pre dve lokality môže namapovať 192.168.50.0/24 lokality A na 172.21.10.0/24 a rovnakú LAN lokality B na 172.21.20.0/24. Overte kandidátov proti každej zúčastnenej sieti, vrátane cloudových VPC a ďalších fondov VPN. Súkromný adresný priestor zdieľa každá organizácia, takže to, že rozsah patrí do RFC 1918, nič nehovorí o tom, či je tu voľný.

Vzdialeným používateľom publikujte alias, nie natívnu podsieť. Natívny rozsah zostáva lokálnym faktom.

Prekladajte v oboch smeroch

Prekladajte v oboch smeroch. Mapovanie cieľa prepisuje adresu aliasu na natívnu adresu v lokalite, ktorá ju vlastní. Mapovanie zdroja prepisuje vzdialeného volajúceho na alias, ktorý ostatné lokality dokážu rozlíšiť.

Statické mapovanie jedna k jednej je deterministické a to neznamená, že implementácia je bezstavová. Spätný preklad môže závisieť od stavu spojenia a prepnutie pri zlyhaní alebo asymetrické cesty môžu pokaziť plán, ktorý to ignoruje. Dokumentácia platformy určuje, ktorý z týchto prípadov platí.

Presná fáza, v ktorej sa uplatňujú politika, selektory a trasy, sa líši medzi IPsec založeným na politikách, tunelmi založenými na trasách a ďalšími produktmi. Navrhujte pre ten, ktorý prevádzkujete.

Preveďte plán cez prekrytie

V hube priraďte každý prefix aliasu ceste lokality, ktorá ho vlastní, a povoľte iba tranzit, ktorý úloha potrebuje. V sieti typu mesh každý relevantný partner potrebuje rovnaký prefix a znalosť politiky. Pridanie tunelov samo o sebe neopraví nejednoznačné adresovanie.

Publikovanie celej podsiete je širšie ako publikovanie jednej služby. Ak treba len niekoľko strojov alebo portov, držte pravidlá prístupu užšie ako mapovanie.

Preklad hlavičiek neprepisuje užitočné zaťaženie aplikácie. Presmerovania, vložené adresy v konfiguračných súboroch a povolenia založené na zdroji môžu stále niesť natívnu adresu. Testujte cestu aplikácie, nielen ping. Fungujúca odpoveď ICMP dokazuje, že mapovanie existuje, a nič nehovorí o tom, či aplikácia alias prijíma.

Opravte názvy, ktoré každý volajúci vidí

Dajte názvom údržby odpovede, ktoré zodpovedajú pohľadu volajúceho. Ak vzdialený inžinier preloží názov hostiteľa, mal by vrátiť adresu aliasu pre túto lokalitu, nie zdieľaný natívny rozsah.

Pred prvým oknom údržby skontrolujte zobrazenia DNS pre každú lokalitu. Názov, ktorý sa preloží do natívnej podsiete, vracia volajúceho späť do nejednoznačnosti, ktorú mal plán odstrániť.

Zaznamenajte a overte pre každú lokalitu

Prijmite každú lokalitu samostatne od skutočného volajúceho a potvrďte, ktorý stroj odpovedal. Zaznamenajte spolu natívnu adresu, alias, vlastniacu bránu a povolenú službu.

Práve tento zoznam zachováva rozlíšenie, keď príde tretia lokalita s rovnakou predvolenou LAN. Príručka IPsec NAT založeného na politikách dokumentuje jeden konkrétny model prekladu; nie je zmluvou pre každú platformu.