Planificați subrețelele înainte de un VPN între locații: renumerotați sau traduceți

Două birouri folosesc ambele 192.168.1.0/24 pentru că nimeni nu a planificat altfel, iar tunelul este de așteptat să rezolve asta. Nu poate: un router nu poate face aceeași adresă privată să însemne două locuri diferite. Munca ce împiedică asta se face înainte de a fi tastat primul parametru al tunelului.

Inventariați fiecare interval, inclusiv pe cele uitate

Adunați LAN-urile, segmentele de servere, pool-urile de clienți pentru acces de la distanță, intervalele VPC din cloud și orice rețele de containere sau de suprapunere pe care gazdele trebuie să le atingă. Pool-urile de clienți sunt cele pe care oamenii le uită și se suprapun cu un interval de birou surprinzător de des pentru că ambele au fost alese din aceeași valoare implicită. Includeți rețeaua de management și orice segment din afara benzii.

Notați proprietarul, gateway-ul, scopul și dacă prefixul trebuie să fie accesibil din cealaltă locație. Un prefix care nu trebuie să traverseze niciodată tunelul nu trebuie să fie unic, iar știind asta se reduce munca de renumerotare.

Faceți IPv6 separat, pentru că planul și suprapunerile sale sunt independente.

Comparați prefixe, nu adrese familiare

Două rețele cu adrese de gazdă diferite se pot totuși suprapune, pentru că suprapunerea este o proprietate a măștilor, nu a numerelor pe care oamenii le țin minte. 10.20.0.0/16 conține 10.20.30.0/24 indiferent dacă cineva o spune cu voce tare. Comparați perechi complete de prefixe și verificați agregatele față de rețelele mai mici din ele. De aceea verificarea aparține unei foi de calcul, nu capului cuiva.

Aceeași verificare se aplică pool-ului de clienți al VPN-ului însuși și oricărui interval tradus pe care intenționați să îl introduceți, pentru că un interval tradus care se ciocnește este mai rău decât suprapunerea inițială.

Este suficient un tabel de prefixe cu măști; o diagramă fără măști nu.

Decideți ce trebuie să traverseze de fapt

O locație poate conține treizeci de subrețele în timp ce o rețea de servicii are nevoie de acces de la distanță. Porniți de la acea cerință și anunțați doar ce are nevoie, pentru că anunțurile mai mici și regulile de acces corespunzătoare sunt mai ușor de verificat și mai greu de lărgit din greșeală. A anunța fiecare interval privat în uz este un obicei care transformă un tunel într-un pod. Cu cât anunțul este mai îngust, cu atât raza de impact a unei erori viitoare este mai mică.

DNS-ul privat trebuie să returneze adrese pe care clienții vizați le pot atinge, așa că un nume care indică un interval neanunțat sau suprapus rămâne stricat chiar și când căutarea reușește.

Scrieți lista de acces înainte de configurația tunelului, nu după ce aceasta eșuează.

Renumerotați sau traduceți și cunoașteți costul

Renumerotarea unei rețele este de obicei remediul cel mai clar pe termen lung și atinge rezervările, dispozitivele, DNS-ul, regulile de firewall și tot ce are o adresă încorporată într-o configurație. Traducerea unui interval de acces este alternativa când renumerotarea nu este practică, iar costul este identitatea sursei plus o clasă de protocoale care încorporează adrese în payload. Alegeți unul și duceți-l la capăt, pentru că o rețea pe jumătate renumerotată este mai rea decât ambele opțiuni.

Indiferent ce alegeți, documentați atât adresa originală, cât și cea prezentată, pentru că fiecare conversație ulterioară de depanare are nevoie de ambele.

O soluție fără cale de întoarcere nu este o soluție.

Folosiți o matrice de rute ca test de acceptare

Încheiați cu o matrice: prefix local, prefix la distanță, serviciu permis și gateway de întoarcere. Acel tabel este testul de acceptare când tunelul urcă și este și documentul pe care îl va citi următorul inginer. Testați de pe gazde reale din subrețelele alese, nu de pe gateway-uri.

Un ping între adresele tunelului dovedește că tunelul există și nimic despre planul de adrese din spate.

Păstrați matricea împreună cu configurația tunelului, iar următoarea adăugare de locație începe din date, nu din memorie. ghidul strongSwan pentru redirecționare acoperă partea de gateway odată ce planul există.