Troubleshooting noodingang datacenter

“Een separate routing-engine”

Situatieschets

Een eindklant had behoefte aan een noodingang in het datacenter, voor het geval de reguliere toegangsmethode niet werkte. Randvoorwaarde bij het opzetten van deze ingang was dat deze vanaf iedere locatie toegankelijk moest zijn, ongeacht waar de gebruiker zich op dat moment bevond. Er was voor deze constructie een 4G-modem aangeschaft met een vast publiek IP-adres. Dit modem was aangesloten op de corporate firewall, waarop men een SSL-VPN wou termineren.
Het lukte het lokale beheerteam al bijna een half jaar niet om deze constructie werkend te krijgen. Bij aanvang van mijn opdracht bij de klant werd ik gevraagd de gebouwde constructie te bekijken, en uit te zoeken waarom deze niet naar behoren werkte.

Methode

Ik ben in gesprek gegaan met de beheerder die de bestaande constructie had gebouwd, en heb geïnventariseerd wat er precies wel en niet werkte. Het was me duidelijk dat het mogelijk was om het WAN-IP van het modem te bereiken vanaf het internet. Het was daarnaast mogelijk om vanaf een interne node het LAN_IP van het 4G-modem te bereiken. Een connectiviteitsvraagstuk was hiermee uitgesloten.

Zodra het me duidelijk was dat het mogelijk was om vanaf een interne node het LAN-IP van het 4G-modem te bereiken heb ik gekeken of er sprake was van onjuiste firewall regels. Zodra problemen in deze hoek uitgesloten waren heb ik uitgetekend wat er precies met een datapakket gebeurde vanaf het moment dat deze binnenkwam op het 4G-modem, naar de firewall gestuurd werd, en waar het retourverkeer naartoe gestuurd werd. Een en ander heb ik uitgetekend en onderbouwd met de aanwezige packet-analyzers. Deze manier van werken valt onder het zogenaamde “follow-the-path” troubleshooten; Je volgt een datastroom van begin tot eind en onderzoekt en controleert iedere stap in dit datapad.

Resultaat

Aan de hand van de situatieschets en packet-analyse heb ik de bouwer van de constructie aan kunnen tonen dat het 4G-modem het bron-adres van het verkeer niet transleerde naar een LAN-adres (zogenaamd source-NAT-en). Doordat er geen vaste route voor deze bron bestaat (diverse medewerkers kunnen immers vanaf een willekeurige IP-adres aanmelden) en de ingang niet de reguliere internet-verbinding betreft, werd retourverkeer door de firewall naar de zogenaamde gateway-of-last-resort gestuurd. Het verkeer nam dus niet hetzelfde pad retour als waarover het op de firewall aangekomen was. Ik heb de klant voorgesteld het bron-verkeer te NAT-en, of een separate routing-engine te gebruiken. De klant heeft uiteindelijk besloten een separate routing-engine te gebruiken. Ik heb deze constructie samen met de eerder genoemde beheerder gebouwd, en er zorg voor gedragen dat het mogelijk was om verkeer in het andere routing-domein te bereiken. De constructie werkt nu naar behoren, en voldoet aan de wensen en eisen die de klant gesteld heeft.

Conclusie

Door op een gestructureerde manier te werk te gaan, heb ik een langlopend probleem snel en doeltreffend onderzocht en opgelost in een relatief onbekend netwerk. De klant is in dit hele proces actief betrokken geweest, en begrijpt welke keuzes er gemaakt zijn en hoe de constructie precies werkt.