Hvorfor en LAN-vært ARPer efter en OpenVPN-klients adresse

Nåbarhedsproblemer mellem en LAN-vært og en VPN-klient går ofte tilbage til selve adresseplanen. Giv den vært et interface på 10.0.100.0/22, og den behandler hver adresse fra 10.0.100.0 til 10.0.103.255 som direkte forbundet, inklusive en klientpulje, der stille ligger på 10.0.101.0/24. Svaret går aldrig til en router, for fra værtens synspunkt er ingen router involveret. Pakken er adresseret til en nabo og efterspørges på ledningen.

Den mekanisme ligger bag en hel familie af rapporter: tunnelen er oppe, serveren har en rute, og LAN-værten kan stadig ikke nå klienten.

Det /22, der opsluger /24

Læs prefixet som et interval, ikke som en streng. Et /22 rummer 1024 adresser, og 10.0.100.0/22 spænder fra 10.0.100.0 til 10.0.103.255, så en pulje på 10.0.101.0/24 ligger helt inden i det. Fejlen overlever gennemgangen, fordi puljens første oktetter ser anderledes ud end LAN:ets første oktetter, og kun den tredje oktett afslører indeholdelsen. Skriv begge intervaller numerisk ud, før du erklærer dem adskilte.

Den samme indeholdelse kan optræde omvendt. En pulje, der ser fri ud, fordi intet bruger den lige nu, kan stadig falde inden for et prefix, som en eller anden site-router annoncerer, og adresseplanen er det eneste dokument, der viser det.

Direkte forbundet betyder ARP, ikke routing

Når en vært med et /22-interface sender til 10.0.101.25, sammenligner kernen målet med interfacets prefix og finder et match. Pakken bliver et naboopslag i stedet for en routet pakke, og på Ethernet er naboopslaget en ARP-anmodning for den adresse. Hvis adressen tilhører en VPN-klient bag en routet gateway, ejer ingen vært på LAN:et den, så anmodningen forbliver ubesvaret, og pakkerne kasseres. Tunnelen har ikke skylden, og klienten ser aldrig trafikken.

Derfor ser fejlen asymmetrisk ud og indimellem tilbagevendende. VPN-værten kan ofte nå LAN:et, fordi dens egne ruter peger den rigtige vej, mens LAN-værten ikke kan svare, og alt, der cacher en forældet ARP-post, får symptomet til at flimre.

TUN, TAP og hvad hver især bærer

En TUN-enhed bærer IP-pakker, og en TAP-enhed bærer Ethernet-rammer. Et routet TUN-link behøver ikke bære ARP for at levere IP-nåbarhed, og det er præcis derfor, den ubesvarede anmodning ovenfor er forventet og ikke defekt. TAP med en bevidst bro kan udvide broadcastdomænet og få ARP til at virke, men det ændrer, hvad klienten kan se, kræver endepunkter, der understøtter den samme indramning, og er et redesign af netværksmodellen snarere end en reparation af et overlappende prefix. At skifte et routet setup til TAP for at kurere en adresseplanfejl bytter et lille problem for et større.

Notér, hvor ARP-anmodningen dukkede op, og hvilket system der sendte den, før du drager konklusioner. Afsenderen fortæller dig, hvad den tror om målet, ikke hvad tunnelen gør.

Design en pulje, der ikke kan overlappe

Vælg en pulje uden for hvert forbundet prefix og hvert annonceret site-prefix, og tilføj derefter de ruter, der gør den nåbar i begge retninger. Et interval som 10.8.0.0/24 i en ubrugt del af planen er let at ræsonnere om, og et LAN, der skal nå det, får en statisk rute, der peger på VPN-serveren. Ændr tildelingen, de annoncerede ruter, de tilladte kildeadresser og firewallreglerne sammen, for de beskriver ét design og ikke fire indstillinger.

Source NAT på serveren kan skjule puljen bag en LAN-routbar adresse, og det er et legitimt migreringsværktøj. Det omskriver også kilden, så LAN:et mister evnen til at henføre forbindelser til enkelte klienter og anvende regler per klient.

Brug den rigtige klients tildelte adresse og en rigtig applikationsanmodning fra en LAN-vært til accepten, og bekræft derefter, at svaret følger den planlagte gateway i stedet for ledningen.