Planificați intervalele private de adrese VPN înainte ca site-urile să se ciocnească

Două site-uri care folosesc ambele 192.168.1.0/24 pot fiecare ajunge la internet și totuși să nu ajungă unul la altul. Gateway-ul nu raportează nicio eroare; instalează o singură rută pentru acel prefix și trimite fiecare pachet către partenerul care l-a revendicat primul. Nimic din handshake, lista de cifruri sau metrica interfeței nu spune care partener greșește. Planificarea adreselor este partea de proiectare care rezolvă asta înainte ca cineva să se conecteze.

Inventariați fiecare spațiu care trebuie să fie accesibil

Notați intervalele care trebuie rutate, nu doar pe cele pe care le configurați. Adică LAN-urile site-urilor, pool-urile de clienți VPN, subrețelele din cloud, rețelele de management și din afara benzii, segmentele de laborator și rețelele din care utilizatorii se conectează de obicei de acasă. Un router de consum livrat ca 192.168.1.0/24 nu este ipotetic, iar același prefix apare în hoteluri și centre de conferințe. Inventarul este un tabel de prefix, proprietar și scop și este singurul artefact care împiedică același interval să fie dat de două ori.

Adăugați prefixele pe care le așteptați în anul următor, pentru că un plan care acoperă doar ziua de azi eșuează la primul site nou. Marcați în fiecare rând cine îl poate schimba, nu doar cine îl deține.

Reutilizarea este ce face asta dificil: spațiul privat este finit și fiecare organizație consideră 10.0.0.0/8 al ei. Un plan nu poate promite că niciun LAN de oaspeți viitor nu va ateriza pe unul dintre prefixele voastre, așa că proiectarea trebuie să spună ce se întâmplă când se întâmplă. Două reguli fac cea mai mare parte a treabă. Puneți pool-urile de clienți într-un singur bloc contiguu pe care îl puteți rezuma și nu alocați niciodată un interval pe care altă echipă îl rutează deja. Tot restul este un registru pe care cineva îl ține la zi.

De ce o suprapunere învinge tabela de rutare

O rută este un prefix plus următorul salt, iar forwarding-ul alege cel mai lung prefix care se potrivește. Când doi parteneri revendică amândoi 192.168.1.0/24, tabela ține o singură intrare pentru el, așa că traficul ambelor site-uri iese prin același tunel. Al doilea site nu este configurat greșit; este inaccesibil pentru că primul răspunde pentru aceleași adrese. Nicio metrică nu le poate separa, pentru că potrivirea are loc înainte ca metricile să fie consultate.

Defecțiunea este asimetrică și ușor de citit greșit. Gazdele din site-ul A ajung la gateway și la unele servicii, în timp ce gazdele site-ului B nu răspund la nimic, iar jurnalul arată un tunel sănătos în ambele direcții. Acel model este o coliziune de adrese, nu o defecțiune de autentificare sau firewall, iar confirmarea ei cere un dump al tabelului comparat cu inventarul.

Dimensionați deliberat pool-ul de clienți și intervalele site-urilor

Un pool de clienți VPN este un interval din care gateway-ul dă o singură adresă o dată, așa că dimensiunea limitează concurența. Un /24 conține 254 de adrese utilizabile, ceea ce este generos pentru o echipă mică și strâns pentru o sucursală care rulează containere; un /22 nu costă nimic în plus în spațiul privat și elimină discuția. Țineți pool-ul contiguu și departe de fiecare LAN de site, astfel încât ruta rezumată către clienți să nu înghită niciodată un site. Rezervați intervalul chiar și când pool-ul este gol, pentru că un interval nescris este cel pe care îl va aloca următorul inginer.

Site-urile primesc intervale dimensionate pentru gazdele așteptate plus creștere, aliniate pe o graniță care se rezumă curat. Golurile deliberate între alocări nu costă nimic și cumpără spațiu pentru agregare mai târziu.

Apoi verificați direcția pe care oamenii o uită: drumul de întoarcere. Fiecare router de site are nevoie de o rută către pool-ul de clienți, iar concentratorul are nevoie de o rută către fiecare prefix de site pe care îl deservește. Un tabel de prefixe îngrijit fără drum înapoi la pool rămâne un design stricat, iar simptomul este o conexiune unidirecțională care nu răspunde la nimic. Țineți ambele direcții în același tabel și revizuiți-l ori de câte ori se adaugă un site.

Traducerea și renumerotarea rezolvă probleme diferite

Când există deja o suprapunere, există două opțiuni corecte și una incorectă. Renumerotarea elimină coliziunea definitiv și costă o fereastră de mentenanță plus fiecare adresă codată fix pe care ați uitat-o. Traducerea adreselor mapează intervalul privat al unei părți într-un alt interval la marginea tunelului, ceea ce lasă ambele site-uri neatinse, dar adaugă stare, rupe protocoalele care încorporează adrese și face jurnalele mai greu de citit. Opțiunea incorectă este o rută de gazdă către un singur server, care trece un test și eșuează în tot restul.

Alegeți după control și durată de viață. Un site pe care îl dețineți și pe care îl puteți planifica aparține căii renumerotării; o rețea de partener pe care nu o puteți atinge, folosită pentru o singură aplicație, este candidată la traducere cu o mapare documentată. Scrieți acea mapare, pentru că o traducere care există doar în interiorul unui fișier de configurare dispare în momentul în care fișierul este înlocuit.

Testați din partea îndepărtată înainte de a implementa

Testați dintr-o rețea care nu găzduiește gateway-ul, pentru că LAN-ul propriu al gateway-ului ascunde majoritatea erorilor de rutare. Conectați un client în spatele unui router de acasă obișnuit, apoi ajungeți la un serviciu pe fiecare site și la unul din interiorul pool-ului de clienți. Testați și direcția inversă, de la o gazdă de site la client, pentru că drumurile de întoarcere eșuează independent. Un test care doar face ping la gateway dovedește că tunelul este sus și nimic mai mult.

Țineți intervalele, proprietarii și mapările de traducere într-un singur registru partajat pe care următorul site îl citește înainte de a aloca ceva. Revizuiți-l când se adaugă un site și tratați un interval nedocumentat ca defect, nu ca surpriză.

Registrul este rezultatul. Un plan care trăiește în memoria a trei oameni eșuează prima dată când unul dintre ei este în concediu, iar o suprapunere găsită în producție costă mai mult decât ar fi costat tabelul.