Twee locaties, één subnet: bouw voor elk een aliasweergave

Twee klantlocaties draaien beide 192.168.50.0/24, en een externe ingenieur moet op elk daarvan een printer op hetzelfde adres bereiken. Geen enkele routingtruc lost die dubbelzinnigheid alleen op. Elke locatie heeft een eigen adresweergave nodig, en de gateway moet de locatie uit die weergave kiezen voordat hij iets doorstuurt.

Het plan heeft vier delen: aliasprefixen, beide vertaalrichtingen, overlaybeleid en namen. Elk moet met de andere overeenkomen.

Kies één aliasprefix per locatie

Wijs elke locatie een volledige aliasprefix toe die aan niemand anders in de omgeving toebehoort. Een plan voor twee locaties kan 192.168.50.0/24 van locatie A toewijzen aan 172.21.10.0/24 en het identieke LAN van locatie B aan 172.21.20.0/24. Controleer de kandidaten tegen elk deelnemend netwerk, inclusief cloud-VPC’s en andere VPN-pools. Privé-adresruimte wordt door elke organisatie gedeeld, dus dat een bereik RFC 1918 is zegt niets over of het hier vrij is.

Publiceer de alias, niet het oorspronkelijke subnet, naar externe gebruikers. Het oorspronkelijke bereik blijft een lokaal feit.

Vertaal in beide richtingen

Vertaal in beide richtingen. Doeltoewijzing herschrijft een aliasadres naar het oorspronkelijke adres op de locatie die het bezit. Brongebruik herschrijft de externe beller naar een alias die andere locaties kunnen onderscheiden.

Een statische een-op-een-toewijzing is deterministisch, en dat maakt de implementatie niet staatloos. Omgekeerde vertaling kan afhangen van de verbindingsstatus, en failover of asymmetrische paden kunnen een plan breken dat dat negeert. De documentatie van het platform bepaalt welke van die gevallen geldt.

De exacte fase waarin beleid, selectors en routes gelden verschilt tussen beleidsgebaseerde IPsec, routegebaseerde tunnels en andere producten. Ontwerp voor degene die je draait.

Draag het plan door de overlay

In een hub wijs je elke aliasprefix toe aan het locatiepad dat hem bezit en sta je alleen het transit toe dat de taak nodig heeft. In een mesh heeft elke relevante peer dezelfde prefix en beleidskennis nodig. Tunnels toevoegen lost dubbelzinnige adressering niet op zichzelf op.

Publicatie van het hele subnet is breder dan publicatie van één dienst. Als er maar een paar machines of poorten nodig zijn, houd de toegangsregels smaller dan de toewijzing.

Headertranslatie herschrijft applicatieladingen niet. Omleidingen, ingebedde adressen in configuratiebestanden en op bron gebaseerde machtigingen kunnen allemaal nog steeds het oorspronkelijke adres dragen. Test het applicatiepad, niet alleen de ping. Een werkend ICMP-antwoord bewijst dat de toewijzing bestaat en zegt niets over of de applicatie de alias accepteert.

Corrigeer de namen die elke beller ziet

Geef onderhoudsnamen antwoorden die bij de weergave van de beller passen. Als de externe ingenieur een hostnaam oplost, moet die het aliasadres voor die locatie teruggeven, niet het gedeelde oorspronkelijke bereik.

Controleer DNS-weergaven per locatie vóór het eerste onderhoudsvenster. Een naam die naar het oorspronkelijke subnet oplost, stuurt de beller terug naar de dubbelzinnigheid die het plan moest wegnemen.

Registreer en verifieer per locatie

Accepteer elke locatie afzonderlijk van een echte beller en bevestig welke machine antwoordde. Registreer het oorspronkelijke adres, de alias, de bezittende gateway en de toegestane dienst samen.

Die inventaris is wat het onderscheid bewaart wanneer een derde locatie met hetzelfde standaard-LAN opduikt. De beleidsgebaseerde IPsec NAT-gids documenteert één concreet vertaalmodel; het is geen contract voor elk platform.