Com pressupostar l’espai d’adreces per a una VPN de diversos llocs
Els extrems del túnel, els enllaços interns, les LAN protegides i la subxarxa de la passarel·la del proveïdor són quatre pressupostos. Dimensiona cada un segons la funció i després comprova què permet la plataforma.
Quina mida ha de tenir la subxarxa VPN no té resposta fins que no anomeneu quines adreces compteu. En un disseny aquestes adreces són els dos extrems d’un enllaç de túnel numerat, en un altre són la LAN de l’oficina darrere d’un túnel basat en polítiques, i en un tercer són la infraestructura reservada d’una passarel·la gestionada. Tres objectes, tres pressupostos, i la majoria d’errors de dimensionament vénen d’omplir una columna amb el número d’una altra.
Quatre papers, quatre preguntes diferents
El transport exterior és l’adreça a què es connecta un parell, així que la seva mida segueix l’adreçament públic o el del proveïdor, mai el nombre de dispositius al darrere. Els enllaços de túnel interns només existeixen en dissenys que numeren una interfície virtual, i allà el recompte segueix les adjacències de la topologia. Els prefixos de LAN protegida segueixen les xarxes reals i el seu pla de creixement. La infraestructura reservada pel proveïdor segueix el que documenta el servei gestionat.
Només el tercer d’aquests té cap relació amb quants portàtils conté l’oficina. Aquesta única confusió explica la majoria de les discussions.
Escriviu els quatre papers com a columnes separades abans d’obrir una calculadora. Cadascun rep la seva assignació, propietari i supòsit de creixement, i cap no hereta la mida d’un altre. Quan un disseny no té cap enllaç intern numerat, aquella columna és buida en lloc de petita, i una columna buida és un fet que val la pena enregistrar per al següent revisor.
Comptar blocs: què costa realment un /30
Un enllaç punt a punt necessita dues adreces i consumeix un bloc la mida del qual depèn de la plataforma. Un /30 conté quatre adreces, dues de les quals solen ser utilitzables, així que dotze enllaços consumeixen quaranta-vuit adreces al pla mentre ofereixen vint-i-quatre extrems. Un /31 conté dues adreces i totes dues són utilitzables, cosa que redueix l’aritmètica a la meitat, però només on tots dos extrems ho accepten.
RFC 3021 defineix el model de dues adreces, i el suport és una propietat dels extrems i del servei, no de les bones intencions. Una API de proveïdor pot imposar el seu propi requisit de màscara a una opció de túnel intern, i un RFC general no anul·la una restricció documentada. Comproveu què declara la vostra plataforma abans de resumir el pressupost, perquè la diferència entre quaranta-vuit i vint-i-quatre adreces decideix si el pla cap al rang reservat. Feu l’aritmètica en lloc de confiar-hi al final d’un dia llarg.
ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31Multipliqueu només quan la topologia estigui decidida. Dotze enllaços separats i una superposició multipunt amb dotze participants produeixen totals molt diferents a partir del mateix recompte de seus.
La subxarxa de la passarel·la gestionada no és un pool de clients
Un servei gestionat sovint reserva una subxarxa per a la seva pròpia infraestructura de passarel·la, i aquesta subxarxa la consumeix el servei en lloc de lliurar-la als clients. Té una mida documentada, de vegades un nom documentat, i cap relació amb quants usuaris es connecten. Tractar-la com el pool d’adreces per a màquines remotes produeix un disseny que s’esgota el primer matí carregat.
Llegiu el requisit del proveïdor com un cost fix, tal com tractaríeu una unitat de rack. No forma part del pressupost del prefix protegit.
La mateixa lectura s’aplica als noms. Una subxarxa la finalitat documentada de la qual és la infraestructura de passarel·la és infraestructura per convenció en aquell servei, i reanomenar-la per encaixar amb el vostre esquema trenca el desplegament en lloc de millorar el diagrama. Manteniu els noms i les mides del proveïdor, i gasteu el vostre esquema de numeració en les parts que controleu.
Documenteu el pla perquè sobrevisqui a la segona seu
Un pla que viu al cap d’un sol enginyer falla en la primera superposició entre un prefix d’oficina i el rang per defecte d’un router domèstic. Publiqueu les assignacions amb els seus propietaris i indiqueu quin extrem de cada enllaç assigna quina adreça. Les rutes o els selectors encara s’han d’anunciar, perquè numerar un enllaç intern no publica una LAN per si sol.
Enregistreu el supòsit de creixement darrere de cada bloc, perquè aquesta és la part que cap lector posterior no pot reconstruir només a partir de les adreces.
Després proveu el pla amb els casos incòmodes: una seu que arriba amb un prefix que ja feu servir, un enllaç l’extrem remot del qual gestiona una altra persona, i una regió el requisit de proveïdor de la qual difereix del primer que vau documentar. Si qualsevol d’aquests força un redisseny, el que teníeu era un diagrama i no una política. Un pla que els sobreviu és prou curt per seure al repositori al costat de la configuració del túnel, que és exactament on la següent persona el buscarà.