Varför en LAN-värd ARPar efter en OpenVPN-klients adress

Nåbarhetsproblem mellan en LAN-värd och en VPN-klient går ofta tillbaka till själva adressplanen. Ge den värden ett gränssnitt på 10.0.100.0/22 och den behandlar varje adress från 10.0.100.0 till 10.0.103.255 som direkt ansluten, inklusive en klientpool som tyst ligger på 10.0.101.0/24. Svaret går aldrig till en router, för från värdens perspektiv är ingen router inblandad. Paketet är adresserat till en granne och efterfrågas på tråden.

Den mekanismen ligger bakom en hel familj av rapporter: tunneln är uppe, servern har en rutt och LAN-värden kan fortfarande inte nå klienten.

Det /22 som sväljer /24

Läs prefixet som ett intervall, inte som en sträng. Ett /22 rymmer 1024 adresser, och 10.0.100.0/22 sträcker sig från 10.0.100.0 till 10.0.103.255, så en pool på 10.0.101.0/24 ligger helt innanför det. Misstaget överlever granskningen eftersom poolens första oktetter ser annorlunda ut än LAN:ets första oktetter, och bara den tredje oktetten avslöjar inneslutningen. Skriv ut båda intervallen numeriskt innan du förklarar dem separata.

Samma inneslutning kan uppträda omvänt. En pool som ser ledig ut eftersom inget använder den just nu kan ändå falla inom ett prefix som någon platsrouter annonserar, och adressplanen är det enda dokumentet som visar det.

Direkt ansluten betyder ARP, inte routing

När en värd med ett /22-gränssnitt skickar till 10.0.101.25 jämför kärnan målet med gränssnittets prefix och hittar en träff. Paketet blir en grannuppslagning i stället för ett routat paket, och på Ethernet är grannuppslagningen en ARP-förfrågan för den adressen. Om adressen tillhör en VPN-klient bakom en routad gateway ägs den inte av någon värd på LAN:et, så förfrågan förblir obesvarad och paketen kastas. Tunneln har ingen skuld, och klienten ser aldrig trafiken.

Det är därför felet ser asymmetriskt ut och stundtals återkommande. VPN-värden kan ofta nå LAN:et eftersom dess egna rutter pekar rätt, medan LAN-värden inte kan svara, och allt som cachar en gammal ARP-post får symtomet att fladdra.

TUN, TAP och vad var och en bär

En TUN-enhet bär IP-paket, och en TAP-enhet bär Ethernet-ramar. En routad TUN-länk behöver inte bära ARP för att leverera IP-nåbarhet, och det är precis därför den obesvarade förfrågan ovan är väntad och inte trasig. TAP med en medveten brygga kan utöka broadcastdomänen och få ARP att fungera, men det ändrar vad klienten kan se, kräver ändpunkter som stöder samma inramning och är en omdesign av nätmodellen snarare än en reparation för ett överlappande prefix. Att byta en routad driftsättning till TAP för att bota ett adressplanfel byter ett litet problem mot ett större.

Anteckna var ARP-förfrågan dök upp och vilket system som sände den innan du drar slutsatser. Avsändaren berättar vad den tror om målet, inte vad tunneln gör.

Designa en pool som inte kan överlappa

Välj en pool utanför varje anslutet prefix och varje annonserat platsperfix och lägg sedan till de rutter som gör den nåbar i båda riktningarna. Ett intervall som 10.8.0.0/24 i en oanvänd del av planen är lätt att resonera kring, och ett LAN som behöver nå det får en statisk rutt som pekar på VPN-servern. Ändra tilldelningen, de annonserade rutterna, de tillåtna källadresserna och brandväggsreglerna tillsammans, för de beskriver en design och inte fyra inställningar.

Source NAT på servern kan dölja poolen bakom en LAN-routbar adress, och det är ett legitimt migreringsverktyg. Det skriver också om källan, så LAN:et förlorar förmågan att hänföra anslutningar till enskilda klienter och att tillämpa regler per klient.

Använd den riktiga klientens tilldelade adress och en riktig applikationsförfrågan från en LAN-värd för godkännandet, och bekräfta sedan att svaret följer den planerade gatewayen i stället för tråden.