Overbrugde locaties hebben nog steeds een beslissing over de lokale internetuitgang nodig

De VLAN-uitbreiding verliep schoon: hosts op beide locaties zien elkaar, bestandsshares werken en printers antwoorden. Dan merkt iemand op de kleinere locatie dat elke download de internetlijn van de andere locatie gebruikt, en het ticket komt binnen als een bandbreedteklacht. De brug deed precies wat ervan gevraagd werd. Ze droeg frames tussen twee gebouwen en had nooit een mening over welke router die frames voor internet moesten gebruiken.

De brug draagt frames, geen beslissingen

Een uitbreiding op laag 2 laat twee locaties op één broadcastdomein lijken, dus ARP-verzoeken, DHCP-broadcasts en verkeer binnen hetzelfde subnet gaan allemaal door de tunnel. Dat is de hele dienst die het levert. Niets in de brug inspecteert een bestemmingsadres, vergelijkt het met de uplink van een locatie of stuurt verkeer naar de dichterbij gelegen uitgang. Elke client neemt nog steeds zijn eigen lokale of externe beslissing met het adres en masker waarmee hij is geconfigureerd.

Zet twee routers op dat gedeelde subnet en beide worden plausibele gateways, of een van beide nu dicht bij de client staat die hem gebruikt of niet.

Hoe een client zijn gateway kiest

De IPv4-beslissing die in RFC 1122 wordt beschreven is eenvoudig. Een bestemming binnen het aangesloten subnet van de client wordt rechtstreeks bereikt, met ARP, en een bestemming daarbuiten gaat naar de geconfigureerde standaardgateway. Daarom kan verkeer binnen hetzelfde subnet tussen de locaties de brug oversteken zonder enige betrokkenheid van een router, en daarom hangt internetverkeer volledig af van het gatewayadres dat de client heeft ontvangen. De twee gedragingen zijn onafhankelijk, en een werkende bestandsshare bewijst alleen de eerste.

Als een client op de kleine locatie is geconfigureerd met de router van de grote locatie, gaan zijn internetframes eerst door de tunnel en komen ze daar naar buiten.

Het wijzigen van de eigen standaardroute van het VPN-apparaat verplaatst de gateway van die client niet, omdat de client het apparaat helemaal niet als router gebruikt. Het apparaat heeft ook een aparte route naar zijn verre peer nodig zodat de tunnel die die frames draagt blijft staan, en het door elkaar halen van die twee is hoe een bruguitbreiding zijn eigen transport onderuit haalt.

Laat DHCP de bedoelde uitgang uitdrukken

Optie 3 in een DHCP-antwoord levert een lijst met routeradressen op het subnet van de client, in volgorde van voorkeur, en clients nemen meestal de eerste die antwoordt. Het mechanisme is in orde; het eigendom is waar ontwerpen misgaan. Noteer wat een echte lease op elke locatie oplevert in plaats van aan te nemen dat de dichtstbijzijnde DHCP-server de dichtstbijzijnde gateway uitgeeft.

Draai één gecoördineerde allocator, of twee die expliciet voor hetzelfde beleid zijn geconfigureerd, en geef het beleid een eigenaar. Een tweede onafhankelijke allocator op de externe locatie creëert geen lokaliteit, hij creëert twee autoriteiten voor hetzelfde broadcastdomein.

Wijs één gatewayadres niet toe aan twee onafhankelijk actieve routers alleen om de instellingen van beide locaties identiek te laten lijken. Een gedeeld virtueel adres over een overbrugd segment is een ontwerp voor redundantie op de eerste hop met eigen eisen, en een zelfgemaakte versie levert ARP-conflicten op die op periodiek pakketverlies lijken. Als de applicatie echt geen gedeeld laag 2-segment nodig heeft, zijn gescheiden gerouteerde prefixen met lokale standaardgateways eenvoudiger te beheren en makkelijker uit te leggen tijdens een incident.

Test de vier dingen apart

Vraag om vier observaties, niet één. Neem op elke locatie een nieuwe DHCP-lease en noteer de router en het masker die hij kreeg. Bereik een dienst in hetzelfde subnet op de andere locatie en bevestig dat het pad de brug is en geen gerouteerde omweg. Haal op elke locatie iets van het openbare internet en bevestig welke uplink het droeg. Laat dan de tunnel vallen en kijk wat er breekt, want een locatie die alle verbinding verliest wanneer de brug faalt, was afhankelijk van de verre gateway zonder dat iemand het merkte.

Die vier resultaten vertellen je of je een brug tussen locaties, een lokale uitgang of een toevallige backhaul hebt, en het verzamelen kost tien minuten.

Het ontwerpprincipe is niet glamoureus: overbruggen bepaalt de bereikbaarheid, DHCP bepaalt de gateway, en de routingtabel op het apparaat bepaalt het eigen pad van de tunnel. Houd de drie in aparte gesprekken, want één wijziging die alle drie probeert te repareren, breekt meestal twee.