Raad het kantoorprefix niet uit één serveradres

Begin met het adres dat je hebt gekregen en weersta dan de neiging om het uit te breiden naar iets wat netjes voelt. Eén server op 10.22.8.19 zegt niets over de vraag of het kantoor 10.22.8.0/24, 10.22.0.0/16 of een handvol verspreide /28s bezit. 10.0.0.0/8 kiezen omdat het getal met 10 begint, vangt thuisnetwerken, containerbereiken en partnerkoppelingen die je niet bedoelde. Het prefix is een grens die je moet verkrijgen, niet een die je afleidt.

Een prefixlengte beschrijft hoeveel leidende bits significant zijn; hij beschrijft niet wie het bereik bezit.

Een serveradres is geen netwerk

Een server, een subnet en een locatie zijn drie verschillende dingen. Eén dienst kan in een klein toegewijd subnet zitten terwijl de rest van het kantoor aparte bereiken bezet, en een hostroute kan volstrekt passend zijn voor een dienst die bewust één adres heeft. Dat stopt wanneer de locatie doorverwijst naar een andere host, zich via een aparte server authenticeert of van adres verandert. Die afhankelijkheden zijn de werkelijke eis, en het loont om ernaar te vragen voordat er een prefix wordt geïnstalleerd.

Een subnetcalculator vertaalt een bekend prefix naar een masker, een bereik of een hostlijst. Hij kan geen organisatorische grens afleiden uit één hostnaam, en zijn uitvoer als autoriteit behandelen is hoe onverwante netwerken uiteindelijk gerouteerd worden.

Vraag om de goedgekeurde prefixen

Haal de bestemmingsbereiken bij wie de VPN of het netwerk beheert. Er kunnen meerdere afzonderlijke prefixen zijn en een privé-DNS-server op een andere locatie, die vaak vergeten wordt totdat namen falen. Leg ze vast als een goedgekeurde lijst met een eigenaar en een datum, niet als een bereik dat uit een voorbeeld is gereconstrueerd. Is de lijst lang, dan is dat informatie over het netwerk en geen uitnodiging om hem samen te vatten tot iets breders.

Een alleen-lezen routeopzoeking op de Mac, gericht op de bestemming die je aangaat, toont welk pad nu in gebruik is. Dat is huidig gedrag, geen machtiging.

Controleer overlap voordat je iets toepast

Vergelijk de goedgekeurde prefixen met elk lokaal bereik voordat je ze toepast: thuis-LAN, containerbruggen, netwerken van virtuele machines en elke andere VPN. Een precieze route naar kantoor kan je nog steeds niet vertellen welk apparaat op dat adres je bedoelde wanneer hetzelfde bereik ook lokaal bestaat; de tabel kent dat begrip niet. Overlap levert symptomen op die op kapotte diensten lijken in plaats van op routefouten, en ze zijn achteraf moeilijk te diagnosticeren.

Laat de ondersteunde eigenaar de prefixen installeren, via de configuratie van de client zelf of de routes die de server pusht, zodat opnieuw verbinden ze herstelt in plaats van te vertrouwen op een opdracht die iemand één keer typte.

Een route is geen toegang

Een prefix de tunnel in routeren geeft geen toegang tot de diensten erbinnen. De gateway moet het verkeer toestaan, de bestemming moet het accepteren en er moet een terugweg bestaan, en elk daarvan kan onafhankelijk van de route falen. Test één beoogde dienst nadat de route er is, en bevestig dan dat een onverwante bron nog steeds geweigerd wordt. Een route die een firewall bereikt is niet hetzelfde als een werkende verbinding.

Documenteer de prefixlijst, de overlapcontrole en de eigenaar samen. Wanneer een adres verandert, zijn die drie wat de volgende persoon nodig heeft.

Het prefix is een afspraak over grenzen. Behandel het zo en de route houdt op een gok te zijn.