Cum să bugetați spațiul de adrese pentru un VPN cu mai multe locații

Cât de mare ar trebui să fie subrețeaua VPN nu are răspuns până nu numiți ce adrese numărați. Într-un proiect acestea sunt cele două capete ale unei legături de tunel numerotate, în altul este rețeaua LAN a biroului din spatele unui tunel bazat pe politici, iar în al treilea este infrastructura rezervată a unui gateway administrat. Trei obiecte, trei bugete, iar majoritatea erorilor de dimensionare vin din completarea unei coloane cu numărul alteia.

Patru roluri, patru întrebări diferite

Transportul exterior este adresa la care se conectează un partener, așa că dimensiunea lui urmează adresarea publică sau pe cea a furnizorului, niciodată numărul de dispozitive din spate. Legăturile de tunel interne există doar în proiectele care numerotează o interfață virtuală, iar acolo numărul urmează vecinătățile topologiei. Prefixele rețelei LAN protejate urmează rețelele reale și planul lor de creștere. Infrastructura rezervată de furnizor urmează ceea ce documentează serviciul administrat.

Doar al treilea dintre ele are vreo legătură cu câte laptopuri are biroul. Exact această confuzie explică majoritatea disputelor.

Scrieți cele patru roluri ca coloane separate înainte de a deschide un calculator. Fiecare primește propria alocare, proprietar și ipoteză de creștere, și niciunul nu moștenește dimensiunea altuia. Când un proiect nu are o legătură internă numerotată, acea coloană este goală și nu mică, iar o coloană goală este un fapt care merită consemnat pentru următorul revizor.

Numărarea blocurilor: cât costă cu adevărat un /30

O legătură punct la punct are nevoie de două adrese și consumă un bloc a cărui dimensiune depinde de platformă. Un /30 conține patru adrese, dintre care două sunt de obicei utilizabile, așa că douăsprezece legături consumă patruzeci și opt de adrese în plan, oferind totodată douăzeci și patru de capete. Un /31 conține două adrese și ambele sunt utilizabile, ceea ce înjumătățește aritmetica, dar numai acolo unde ambele capete acceptă acest lucru.

RFC 3021 definește modelul cu două adrese, iar suportul este o proprietate a capetelor și a serviciului, nu a intențiilor bune. Un API de furnizor poate impune propria cerință de mască asupra unei opțiuni de tunel intern, iar un RFC general nu anulează o restricție documentată. Verificați ce declară platforma înainte de a rezuma bugetul, pentru că diferența dintre patruzeci și opt și douăzeci și patru de adrese decide dacă planul încape în intervalul rezervat. Faceți aritmetica în loc să vă bazați pe ea la finalul unei zile lungi.

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

Înmulțiți doar după ce topologia este stabilită. Douăsprezece legături separate și o suprapunere multipunct cu douăsprezece participanți produc totaluri foarte diferite din același număr de locații.

Subrețeaua gateway-ului administrat nu este un bazin de clienți

Un serviciu administrat rezervă adesea o subrețea pentru propria infrastructură de gateway, iar acea subrețea este consumată de serviciu în loc să fie predată clienților. Are o dimensiune documentată, uneori un nume documentat, și nicio legătură cu câți utilizatori se conectează. Tratarea ei ca bazin de adrese pentru mașini la distanță produce un proiect care se epuizează în prima dimineață aglomerată.

Citiți cerința furnizorului ca un cost fix, așa cum ați trata o unitate de rack. Nu face parte din bugetul prefixului protejat.

Aceeași lectură se aplică numelor. O subrețea al cărei scop documentat este infrastructura de gateway este infrastructură prin convenție în acel serviciu, iar redenumirea ei ca să se potrivească cu schema dumneavoastră strică implementarea în loc să îmbunătățească diagrama. Păstrați numele și dimensiunile furnizorului și cheltuiți propria schemă de numerotare pe părțile pe care le controlați.

Documentați planul ca să supraviețuiască celei de-a doua locații

Un plan care trăiește în capul unui singur inginer eșuează la prima suprapunere dintre un prefix de birou și intervalul implicit al unui router de acasă. Publicați alocările împreună cu proprietarii lor și precizați care capăt al fiecărei legături atribuie care adresă. Rutele sau selectorii trebuie totuși anunțate, pentru că numerotarea unei legături interne nu publică o rețea LAN de la sine.

Consemnați ipoteza de creștere din spatele fiecărui bloc, pentru că aceasta este partea pe care niciun cititor ulterior nu o poate reconstrui doar din adrese.

Apoi testați planul pe cazurile incomode: o locație care vine cu un prefix pe care îl folosiți deja, o legătură al cărei capăt îndepărtat este administrat de altcineva și o regiune a cărei cerință a furnizorului diferă de prima pe care ați documentat-o. Dacă vreuna dintre ele impune o reproiectare, ceea ce aveați era o diagramă, nu o politică. Un plan care le supraviețuiește este suficient de scurt pentru a sta în depozit lângă configurația tunelului, și exact acolo îl va căuta următoarea persoană.