Hogyan tervezzük meg a címteret egy több telephelyes VPN-hez

Annak, hogy mekkora legyen a VPN-alhálózat, nincs válasza addig, amíg meg nem nevezi, mely címeket számolja. Az egyik tervben ezek egy számozott alagútkapcsolat két végpontja, a másikban az iroda LAN-ja egy házirend-alapú alagút mögött, a harmadikban pedig egy felügyelt átjáró fenntartott infrastruktúrája. Három objektum, három költségvetés, és a méretezési hibák többsége abból fakad, hogy az egyik oszlopot egy másik oszlop számával töltik ki.

Négy szerep, négy különböző kérdés

A külső szállítás az a cím, amelyhez a partner csatlakozik, ezért mérete a nyilvános címzését vagy a szolgáltatóét követi, soha nem a mögötte lévő eszközök számát. Belső alagútkapcsolatok csak azokban a tervekben léteznek, amelyek virtuális interfészt számoznak, és ott a szám a topológia szomszédságait követi. A védett LAN-előtagok a valódi hálózatokat és növekedési tervüket követik. A szolgáltató által fenntartott infrastruktúra azt követi, amit a felügyelt szolgáltatás dokumentál.

Ezek közül csak a harmadiknak van köze ahhoz, hány laptop van az irodában. Ez az egyetlen zavar magyarázza a viták többségét.

Írja fel a négy szerepet külön oszlopokként, mielőtt megnyit egy számológépet. Mindegyik saját kiosztást, gazdát és növekedési feltevést kap, és egyik sem örökli a másik méretét. Ha egy tervben nincs számozott belső kapcsolat, az az oszlop üres, nem kicsi, és az üres oszlop olyan tény, amelyet érdemes rögzíteni a következő bíráló számára.

Blokkok számolása: mennyibe kerül valójában egy /30

Egy pont-pont kapcsolat két címet igényel, és olyan blokkot fogyaszt, amelynek mérete a platformtól függ. Egy /30 négy címet tartalmaz, amelyek közül kettő általában használható, így tizenkét kapcsolat negyvennyolc címet fogyaszt a tervben, miközben huszonnégy végpontot kínál. Egy /31 két címet tartalmaz, és mindkettő használható, ami felére csökkenti a számítást, de csak ott, ahol mindkét vég elfogadja.

RFC 3021 határozza meg a kétcímes modellt, és a támogatás a végpontok és a szolgáltatás tulajdonsága, nem a jó szándéké. A szolgáltató API-ja saját maszkkövetelményt írhat elő egy belső alagútbeállításra, és egy általános RFC nem helyezi hatályon kívül a dokumentált korlátot. Ellenőrizze, mit állít a platformja, mielőtt összegzi a költségvetést, mert a negyvennyolc és a huszonnégy cím közötti különbség dönti el, belefér-e a terv a fenntartott tartományba. Számolja ki, ahelyett hogy egy hosszú nap végén megbízik benne.

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

Csak a topológia rögzítése után szorozzon. Tizenkét külön kapcsolat és egy tizenkét résztvevős többpontos átfedés nagyon különböző összegeket ad ugyanabból a telephelyszámból.

A felügyelt átjáró alhálózata nem ügyfélkészlet

A felügyelt szolgáltatás gyakran alhálózatot tart fenn a saját átjáró-infrastruktúrája számára, és ezt az alhálózatot a szolgáltatás fogyasztja el, nem az ügyfelek kapják meg. Dokumentált mérete van, néha dokumentált neve, és semmi köze ahhoz, hány felhasználó csatlakozik. Ha címkészletként kezeljük távoli gépekhez, olyan terv születik, amely az első forgalmas reggelen kimerül.

A szolgáltató követelményét fix költségként olvassa, ahogy egy rack-egységgel bánna. Nem része a védett előtag költségvetésének.

Ugyanez az olvasat érvényes a nevekre. Egy alhálózat, amelynek dokumentált célja az átjáró-infrastruktúra, abban a szolgáltatásban szokás szerint infrastruktúra, és átnevezése, hogy illeszkedjen a saját sémájához, megtöri a telepítést ahelyett, hogy javítaná az ábrát. Tartsa meg a szolgáltató neveit és méreteit, és a saját számozási sémáját arra költse, amit irányít.

Dokumentálja a tervet, hogy túlélje a második telephelyet

Az egyetlen mérnök fejében élő terv az első átfedésnél elbukik egy irodai előtag és egy otthoni router alapértelmezett tartománya között. Tegye közzé a kiosztásokat a gazdáikkal együtt, és mondja meg, melyik kapcsolat melyik vége melyik címet osztja ki. Az útvonalakat vagy szelektorokat továbbra is hirdetni kell, mert egy belső kapcsolat számozása önmagában nem tesz közzé egy LAN-t.

Jegyezze fel az egyes blokkok mögötti növekedési feltevést, mert ez az a rész, amelyet semmilyen későbbi olvasó nem tud pusztán a címekből rekonstruálni.

Utána tesztelje a tervet a kellemetlen eseteken: egy telephely, amely olyan előtaggal érkezik, amelyet már használ, egy kapcsolat, amelynek távoli végét valaki más felügyeli, és egy régió, amelynek szolgáltatói követelménye eltér az első dokumentálttól. Ha bármelyik áttervezést kényszerít ki, akkor ami volt, az ábra volt, nem házirend. Az a terv, amely ezeket túléli, elég rövid ahhoz, hogy a tárolóban az alagút konfigurációja mellett álljon, és pontosan ott fogja keresni a következő ember.