Com dimensionar l’espai d’adreces d’una VPN de lloc a lloc
Els extrems de transport, els enllaços interns, les LAN protegides i les subxarxes de passarel·la són quatre pressupostos separats. Dimensioneu cadascun des de la topologia, no des del nombre de dispositius.
Pregunteu quina mida ha de tenir la subxarxa de la VPN i la resposta honesta és que dins de la pregunta hi poden cabre quatre subxarxes diferents. Una VPN de lloc pot implicar extrems de transport, enllaços de túnel numerats, els prefixos de la LAN protegida i, a les passarel·les gestionades, una subxarxa d’infraestructura que el proveïdor reserva. En un disseny concret només n’existeixen una o dues. Dimensionar-les a partir del nombre de dispositius d’oficina és com un pla acaba amb una /24 que no satisfà ningú.
Anomeneu els quatre rols abans d’assignar res
Els extrems de transport són les adreces que dues passarel·les fan servir per arribar l’una a l’altra per Internet o per un circuit privat, i el seu nombre prové del model de passarel·la i redundància, no de la LAN. Els enllaços de túnel interns només existeixen on el disseny numera una interfície punt a punt, cosa que una configuració IPsec basada en polítiques normalment no fa. Els prefixos protegits són les xarxes reals d’oficina o de VPC que han de ser encaminables, i la subxarxa reservada pel proveïdor pertany al servei gestionat.
Inventarieu què existeix ja abans d’afegir res, perquè l’error car aquí és reutilitzar un prefix que ja s’encamina en un altre lloc. Un túnel oblidat d’un projecte pilot n’hi ha prou per enverinar un pla. Anoteu l’inventari amb dates, perquè el record d’un enllaç desmantellat sobreviu a l’enllaç mateix.
ip -br addr show ip route show | head -40
Aquestes dues ordres donen la vista local de les xarxes connectades i de les rutes que arriben a tot el que hi ha més enllà. Repetiu l’inventari a cada lloc, perquè un pla construït amb la sortida d’un sol lloc xocarà amb la del següent. Recolliu les sortides abans d’assignar un sol bloc.
Compteu enllaços i topologia, no dispositius
Un disseny amb vuit adjacències punt a punt consumeix vuit blocs, no un. A /30 cada bloc gasta quatre adreces per connectar dos amfitrions, així que el pla porta trenta-dues adreces per a setze extrems utilitzables, i aquesta és la xifra que el pressupost ha de cobrir. Una plataforma que admet enllaços /31 en gasta la meitat, però només quan els dos extrems i el servei coincideixen en aquest model. Arrodoniu el pressupost cap amunt i no cap avall, perquè reduir un bloc més tard obliga a renumerar enllaços actius.
Les restriccions del proveïdor manen sobre la pràctica general. Un interval intern documentat pot exigir /30 fins i tot on /31 funciona als vostres encaminadors, i una passarel·la gestionada pot exigir una màscara concreta per a la seva pròpia subxarxa. Llegiu el requisit del servei abans d’aplicar una regla empírica manllevada d’una altra plataforma.
Una superposició multipunt torna a canviar l’aritmètica: una adreça per passarel·la, amb la superposició encarregant-se de l’abast entre elles. Decidiu quina topologia fa servir realment la implementació abans de multiplicar llocs per una mida de bloc.
El creixement mereix la seva pròpia línia al pla. Reservar un interval d’infraestructura coherent és raonable, i també ho és anotar quines assignacions més petites hi queden dins, perquè el següent enginyer no llegeixi la reserva com un sol domini de difusió.
Manteniu la subxarxa de passarel·la fora del conjunt de la LAN
La infraestructura d’una passarel·la gestionada no és un conjunt de clients. Les adreces d’una subxarxa de passarel·la reservada allotgen els components del servei mateix, i els treballadors remots no n’extreuen mai. Dimensionar aquesta subxarxa a partir del nombre d’usuaris és un error de categoria que o bé malgasta un interval gran o bé deixa la passarel·la sense adreces.
El mateix val per als intervals de túnel de les connexions VPN al núvol, on el proveïdor assigna un interval intern petit per túnel per al seu propi ús. Aquest interval no és on viuen els vostres servidors de filial, i no és vostre per repartir-lo.
aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table
Llistar les adreces exteriors confirma què ha assignat el proveïdor i quin túnel redundant està actiu en aquest moment. És més ràpid que llegir un document de disseny escrit abans que la connexió existís.
Registreu rol, propietari i creixement per a cada prefix
Un pla que sobreviu al contacte amb l’explotació declara, per a cada prefix, quin rol hi fa, qui assigna l’extrem remot i quant marge conté. Sense el camp de propietari, dos equips assignen la mateixa /24 en el mateix trimestre i la col·lisió només surt quan aixequen el túnel.
Manteniu aquests intervals lluny dels prefixos domèstics i de filial que arriben per altres túnels, perquè el solapament d’espai és la raó habitual per la qual una connexió de lloc a lloc negocia amb èxit i després no hi passa trànsit.
Assignar adreces d’enllaç internes no anuncia les LAN que hi ha al darrere. Les rutes o selectors de trànsit, els camins de retorn i les regles d’accés són tasques separades, i el pla hauria de dir-ho en lloc d’insinuar que una interfície numerada fa l’encaminament per vosaltres.