Waarom een LAN-host ARP doet voor het adres van een OpenVPN-client

Bereikbaarheidsproblemen tussen een LAN-host en een VPN-client leiden vaak terug naar het adresplan zelf. Geef die host een interface op 10.0.100.0/22 en hij behandelt elk adres van 10.0.100.0 tot 10.0.103.255 als direct verbonden, inclusief een clientpool die stilletjes op 10.0.101.0/24 staat. Het antwoord gaat nooit naar een router, want vanuit de host is er geen router bij betrokken. Het pakket is geadresseerd aan een buur en wordt op de draad opgevraagd.

Dat mechanisme zit achter een hele reeks meldingen: de tunnel is up, de server heeft een route en de LAN-host kan de client nog steeds niet bereiken.

Het /22 dat het /24 opslokt

Lees het prefix als een bereik, niet als een tekenreeks. Een /22 bevat 1024 adressen en 10.0.100.0/22 loopt van 10.0.100.0 tot 10.0.103.255, dus een pool op 10.0.101.0/24 ligt er volledig binnen. De fout overleeft de controle omdat de eerste octetten van de pool er anders uitzien dan de eerste octetten van het LAN, en alleen het derde octet de insluiting verraadt. Schrijf beide bereiken numeriek uit voordat je ze als gescheiden verklaart.

Dezelfde insluiting kan ook omgekeerd optreden. Een pool die vrij lijkt omdat niets hem momenteel gebruikt, kan toch binnen een prefix vallen dat een siterouter aankondigt, en het adresplan is het enige document dat dat laat zien.

Direct verbonden betekent ARP, geen routing

Wanneer een host met een /22-interface naar 10.0.101.25 stuurt, vergelijkt de kernel de bestemming met het prefix van de interface en vindt een overeenkomst. Het pakket wordt een burenopzoeking in plaats van een gerouteerd pakket, en op Ethernet is de burenopzoeking een ARP-verzoek voor dat adres. Hoort het adres bij een VPN-client achter een gerouteerde gateway, dan bezit geen enkele host op het LAN het, dus blijft het verzoek onbeantwoord en worden de pakketten weggegooid. De tunnel is niet de schuldige, en de client ziet het verkeer nooit.

Daarom lijkt de storing asymmetrisch en af en toe onregelmatig. De VPN-host kan het LAN vaak bereiken omdat zijn eigen routes de goede kant op wijzen, terwijl de LAN-host niet kan antwoorden, en alles wat een verouderde ARP-regel cachet, laat het symptoom flikkeren.

TUN, TAP en wat elk draagt

Een TUN-apparaat draagt IP-pakketten, en een TAP-apparaat draagt Ethernet-frames. Een gerouteerde TUN-verbinding hoeft geen ARP te dragen om IP-bereikbaarheid te leveren, en precies daarom is het onbeantwoorde verzoek hierboven te verwachten in plaats van kapot. TAP met een bewuste bridge kan het broadcastdomein uitbreiden en ARP laten werken, maar het verandert wat de client kan zien, vereist eindpunten die dezelfde framing ondersteunen en is een herontwerp van het netwerkmodel in plaats van een reparatie voor een overlappend prefix. Een gerouteerde implementatie naar TAP omzetten om een adresplanfout te genezen, ruilt een klein probleem in voor een groter.

Noteer waar het ARP-verzoek verscheen en welk systeem het uitzond voordat je conclusies trekt. De afzender vertelt je wat hij over de bestemming denkt, niet wat de tunnel doet.

Ontwerp een pool die niet kan overlappen

Kies een pool buiten elk verbonden prefix en elk aangekondigd siteprefix en voeg dan de routes toe die hem in beide richtingen bereikbaar maken. Een bereik zoals 10.8.0.0/24 in een ongebruikt deel van het plan is makkelijk te beredeneren, en een LAN dat er moet komen, krijgt een statische route die naar de VPN-server wijst. Wijzig de toewijzing, de aangekondigde routes, de toegestane bronadressen en de firewallregels samen, want ze beschrijven één ontwerp en niet vier instellingen.

Source-NAT op de server kan de pool verbergen achter een LAN-routeerbaar adres, en het is een legitiem migratie-instrument. Het herschrijft ook de bron, zodat het LAN het vermogen verliest om verbindingen aan afzonderlijke clients toe te schrijven en regels per client toe te passen.

Gebruik voor de acceptatie het werkelijk toegewezen adres van de echte client en een echt applicatieverzoek vanaf een LAN-host, en bevestig dan dat het antwoord de geplande gateway volgt in plaats van de draad.