Hvorfor en LAN-vert ARPer etter en OpenVPN-klients adresse

Tilgjengelighetsproblemer mellom en LAN-vert og en VPN-klient går ofte tilbake til selve adresseplanen. Gi den verten et grensesnitt på 10.0.100.0/22, og den behandler hver adresse fra 10.0.100.0 til 10.0.103.255 som direkte tilkoblet, inkludert en klientpool som stille ligger på 10.0.101.0/24. Svaret går aldri til en ruter, for fra vertens synspunkt er ingen ruter involvert. Pakken er adressert til en nabo og etterspørres på ledningen.

Den mekanismen ligger bak en hel familie av rapporter: tunnelen er oppe, serveren har en rute, og LAN-verten kan fortsatt ikke nå klienten.

Det /22 som svelger /24

Les prefikset som et område, ikke som en streng. Et /22 rommer 1024 adresser, og 10.0.100.0/22 strekker seg fra 10.0.100.0 til 10.0.103.255, så en pool på 10.0.101.0/24 ligger helt innenfor. Feilen overlever gjennomgangen fordi poolens første oktetter ser annerledes ut enn LANets første oktetter, og bare den tredje oktetten avslører inneslutningen. Skriv begge områdene numerisk ut før du erklærer dem atskilt.

Den samme inneslutningen kan oppstå omvendt. En pool som ser ledig ut fordi ingenting bruker den akkurat nå, kan likevel falle innenfor et prefiks som en eller annen stedsruter annonserer, og adresseplanen er det eneste dokumentet som viser det.

Direkte tilkoblet betyr ARP, ikke ruting

Når en vert med et /22-grensesnitt sender til 10.0.101.25, sammenligner kjernen målet med grensesnittets prefiks og finner et treff. Pakken blir et nabo-oppslag i stedet for en rutet pakke, og på Ethernet er nabo-oppslaget en ARP-forespørsel for den adressen. Hvis adressen tilhører en VPN-klient bak en rutet gateway, eier ingen vert på LANet den, så forespørselen forblir ubesvart og pakkene forkastes. Tunnelen har ingen skyld, og klienten ser aldri trafikken.

Derfor ser feilen asymmetrisk ut og av og til tilbakevendende. VPN-verten kan ofte nå LANet fordi dens egne ruter peker riktig vei, mens LAN-verten ikke kan svare, og alt som cacher en utdatert ARP-oppføring får symptomet til å flimre.

TUN, TAP og hva hver av dem bærer

En TUN-enhet bærer IP-pakker, og en TAP-enhet bærer Ethernet-rammer. En rutet TUN-lenke trenger ikke bære ARP for å levere IP-tilgjengelighet, og det er nettopp derfor den ubesvarte forespørselen ovenfor er forventet og ikke ødelagt. TAP med en bevisst bro kan utvide kringkastingsdomenet og få ARP til å virke, men det endrer hva klienten kan se, krever endepunkter som støtter samme innramming, og er en nyutforming av nettverksmodellen snarere enn en reparasjon for et overlappende prefiks. Å bytte en rutet utplassering til TAP for å kurere en adresseplanfeil bytter et lite problem mot et større.

Noter hvor ARP-forespørselen dukket opp og hvilket system som sendte den, før du trekker konklusjoner. Avsenderen forteller deg hva den tror om målet, ikke hva tunnelen gjør.

Design en pool som ikke kan overlappe

Velg en pool utenfor hvert tilkoblede prefiks og hvert annonserte stedsprefiks, og legg deretter til rutene som gjør den tilgjengelig i begge retninger. Et område som 10.8.0.0/24 i en ubrukt del av planen er lett å resonnere om, og et LAN som trenger å nå det, får en statisk rute som peker på VPN-serveren. Endre tildelingen, de annonserte rutene, de tillatte kildeadressene og brannmurreglene sammen, fordi de beskriver én design og ikke fire innstillinger.

Source NAT på serveren kan skjule poolen bak en LAN-rutbar adresse, og det er et legitimt migreringsverktøy. Det skriver også om kilden, så LANet mister evnen til å tilskrive tilkoblinger til enkeltklienter og anvende regler per klient.

Bruk den ekte klientens tildelte adresse og en ekte applikasjonsforespørsel fra en LAN-vert til aksepten, og bekreft deretter at svaret følger den planlagte gatewayen i stedet for ledningen.