Een VPN-client met een LAN-adres staat niet op de LAN

De client maakt verbinding, ontvangt 10.50.0.200 en kan de server op 10.50.0.20 niet bereiken, ook al liggen beide nummers in dezelfde /24. De overtuiging achter die configuratie is dat een adres uit de LAN-prefix de client deel van de LAN maakt. Dat doet het niet. De client zit op een punt-naar-puntlink, de server beschouwt de bestemming als lokaal, en het ontbrekende stuk is een buurantwoord dat niemand stuurt.

De mythe: dezelfde prefix betekent hetzelfde segment

Een adresprefix vertelt een host welke bestemmingen hij rechtstreeks kan bereiken en welke een router nodig hebben. Het vertelt de host niet hoe de bestemming fysiek is aangesloten, en het garandeert zeker niet dat de bestemming op een verzoek op de linklaag kan antwoorden. Dat zijn verschillende vragen, die door verschillende tabellen op de host worden beantwoord. Het masker beantwoordt de eerste en de buurtabel de tweede, en alleen de eerste is vanaf de VPN-kant onder jouw controle.

Wanneer de server naar 10.50.0.200 stuurt, vergelijkt hij de bestemming met zijn eigen masker, besluit dat het adres on-link is, en vraagt het lokale segment naar het hardwareadres dat erbij hoort. Dat verzoek gaat via de Ethernet-interface naar buiten, en de VPN-client is er niet om het te horen.

Niets in de configuratie van de client kan dit van zijn kant oplossen. Het antwoordpad hangt ervan af dat een apparaat op de LAN namens de client antwoordt, of dat de client een adres heeft dat de server niet als lokaal beschouwt.

Wat de lokale host werkelijk met het adres doet

Het gedrag is gemakkelijk te observeren en de moeite waard om te observeren voordat je iets verandert. Kijk op een LAN-host in de buurtabel nadat hij heeft geprobeerd de client te bereiken: een onvolledige of mislukte vermelding is de hele diagnose in één regel. Die regel vertelt je ook dat de fout lokaal is voor het segment en niet ergens in de tunnel.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

De routeopzoeking zal de bestemming als on-link rapporteren via de Ethernet-interface, en dat is precies het probleem. Als de buurvermelding onvolledig blijft terwijl de VPN-sessie actief is, heb je bevestigd dat het ontbrekende stuk de oplossing op de linklaag is en niet routing of firewallbeleid.

Voer dezelfde controle uit vanaf een host in een ander subnet en vergelijk. Een host die de client via een router bereikt heeft helemaal geen buurvermelding nodig, en dat verschil is de ontwerpbeslissing in het klein.

Hoe proxy ARP een volgende hop levert

proxy ARP zorgt ervoor dat de gateway het verzoek op de linklaag beantwoordt namens een bestemming die hij via een andere interface kan bereiken. De LAN-host ontvangt een hardwareadres, stuurt het frame naar de gateway, en de gateway stuurt het pakket door naar de VPN-sessie. Vanuit het oogpunt van de host lijkt de client simpelweg achter de gateway te zitten. Niets aan de configuratie van de client verandert.

De RouterOS ARP-documentatie van MikroTik beschrijft dat gebruik voor dial-inclients die de adresruimte van de aangesloten LAN lenen. Het mechanisme is een reparatie van de buuromzetting, en het werkt omdat de gateway werkelijk op beide paden zit.

Dat is niet hetzelfde als de client in de LAN bruggen. De gateway moet het pakket nog steeds naar de juiste actieve sessie doorsturen, en zijn routing en firewallbeleid moeten de dienst nog steeds toestaan. proxy ARP verandert wie het buurverzoek beantwoordt, niet wie mag praten.

Lees de modusnamen van het platform zorgvuldig. RouterOS scheidt proxy-arp van local-proxy-arp, en de tweede verwerkt verkeer dat via dezelfde interface binnenkomt en vertrekt. Dat zijn geen verwisselbare spellingen, en beide zonder onderscheid inschakelen is geen kortere weg.

Wat proxy ARP je niet geeft

Het biedt geen broadcast- of multicastdetectie. Een client die een dienst via broadcast moet vinden, zal alsnog mislukken, omdat de gateway unicast naar de sessie doorstuurt en de client geen lid maakt van het broadcast-domein van de LAN. Detectieprotocollen die op broadcast vertrouwen zijn een veelvoorkomende bron van meldingen dat het voor het ene wel werkt en voor het andere niet in ontwerpen met geleende adressen.

Het reserveert het adres niet. Als het geleende nummer ook in een DHCP-pool of een statische toewijzing staat, kunnen twee apparaten met hetzelfde adres eindigen en het resulterende gedrag hangt van de timing af. Een geslaagde login is geen reservering.

En het neemt de noodzaak niet weg om af te stemmen met de eigenaar van de LAN. Een proxy ARP-vermelding die de eigenaar van het adresplan verrast, is een supportincident dat op een rustige week wacht.

Vergelijking met een apart gerouteerde pool

Het alternatief is om VPN-clients hun eigen prefix te geven en LAN-hosts daarheen te laten routeren. Dan stuurt de server off-link-antwoorden naar zijn gateway, de gateway routeert het prefix naar het VPN-eindpunt, en op het LAN-segment is helemaal geen buuromzetting nodig. Dat zijn minder bewegende delen dan een geleend adres plus een proxyantwoord.

Dat ontwerp is gemakkelijker te doordenken en gemakkelijker te auditen, omdat het clientbereik zichtbaar gescheiden is van het LAN-bereik. Het kost een route, een terugweg en een toegangsregel, dezelfde dingen die het proxy ARP-ontwerp op een minder voor de hand liggende plek nodig heeft.

Kies bewust tussen de modellen en niet per ongeluk. proxy ARP repareert één specifieke relatie; een gerouteerde pool voorkomt dat die reparatie nodig is. Schrijf op welke je hebt gekozen en waarom, en de volgende persoon hoeft het niet opnieuw te ontdekken uit een mislukte buurvermelding.