En VPN-klient med LAN-adresse er ikke på LAN-et

Klienten kobler til, mottar 10.50.0.200 og når ikke serveren på 10.50.0.20 selv om begge numrene ligger i samme /24. Troen bak den konfigurasjonen er at en adresse fra LAN-prefikset gjør klienten til en del av LAN-et. Det gjør den ikke. Klienten er på en punkt-til-punkt-lenke, serveren tror destinasjonen er lokal, og den manglende brikken er et nabosvar som ingen sender.

Myten: samme prefiks betyr samme segment

Et adresseprefiks forteller en vert hvilke destinasjoner den når direkte og hvilke som trenger en ruter. Det forteller ikke verten hvordan destinasjonen er fysisk tilkoblet, og det garanterer slett ikke at destinasjonen kan svare på en forespørsel på lenkelaget. Det er forskjellige spørsmål, som besvares av forskjellige tabeller på verten. Masken svarer på det første og nabo-tabellen på det andre, og bare det første er under din kontroll fra VPN-siden.

Når serveren sender til 10.50.0.200, sammenligner den destinasjonen med sin egen maske, vurderer at adressen er on-link, og spør det lokale segmentet etter maskinvareadressen som eier den. Forespørselen går ut på Ethernet-grensesnittet, og VPN-klienten er ikke der for å høre den.

Ingenting i klientens konfigurasjon kan rette dette fra dens side. Svarveien avhenger av at en enhet på LAN-et svarer på vegne av klienten, eller av at klienten har en adresse som serveren ikke anser som lokal.

Hva den lokale verten faktisk gjør med adressen

Atferden er lett å observere og verdt å observere før du endrer noe. Se på nabo-tabellen på en LAN-vert etter at den har forsøkt å nå klienten: en ufullstendig eller mislykket oppføring er hele diagnosen på én linje. Den linjen forteller deg også at feilen er lokal for segmentet og ikke et sted inne i tunnelen.

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

Ruteoppslaget vil rapportere destinasjonen som on-link gjennom Ethernet-grensesnittet, og det er nettopp problemet. Hvis nabooppføringen forblir ufullstendig mens VPN-økten er oppe, har du bekreftet at den manglende brikken er oppløsning på lenkelaget og ikke ruting eller brannmurpolitikk.

Kjør den samme kontrollen fra en vert i et annet subnett og sammenlign. En vert som når klienten gjennom en ruter trenger ingen nabooppføring i det hele tatt, og den forskjellen er designbeslutningen i miniatyr.

Hvordan proxy ARP gir et neste hopp

proxy ARP får gatewayen til å svare på forespørselen på lenkelaget på vegne av en destinasjon den kan nå gjennom et annet grensesnitt. LAN-verten mottar en maskinvareadresse, sender rammen til gatewayen, og gatewayen videresender pakken inn i VPN-økten. Fra vertens synspunkt ser klienten bare ut til å være bak gatewayen. Ingenting ved klientens konfigurasjon endres.

MikroTiks RouterOS-ARP-dokumentasjon beskriver den bruken for dial-in-klienter som låner adresseområdet til det tilkoblede LAN-et. Mekanismen er en reparasjon av nabo-oppløsningen, og den virker fordi gatewayen virkelig er på begge veier.

Det er ikke det samme som å bro klienten inn i LAN-et. Gatewayen må fortsatt videresende pakken til riktig aktive økt, og rutingen og brannmurpolitikken må fortsatt tillate tjenesten. proxy ARP endrer hvem som svarer på naboforespørselen, ikke hvem som har lov til å snakke.

Les plattformens modusnavn nøye. RouterOS skiller mellom proxy-arp og local-proxy-arp, og den andre håndterer trafikk som kommer inn og ut gjennom samme grensesnitt. De er ikke utskiftbare stavemåter, og å aktivere begge uten forskjell er ingen snarvei.

Hva proxy ARP ikke gir deg

Det gir ingen broadcast- eller multicast-oppdagelse. En klient som må finne en tjeneste via broadcast, vil fortsatt mislykkes, fordi gatewayen videresender unicast til økten og ikke gjør klienten til medlem av LAN-ets broadcast-domene. Oppdagelsesprotokoller som er avhengige av broadcast, er en vanlig kilde til rapporter om at det virker for én ting og ikke for en annen i design med lånte adresser.

Det reserverer ikke adressen. Hvis det lånte nummeret også står i en DHCP-pool eller en statisk tildeling, kan to enheter ende med samme adresse, og atferden som følger avhenger av timing. En vellykket innlogging er ikke en reservasjon.

Og det fjerner ikke behovet for å koordinere med eieren av LAN-et. En proxy ARP-oppføring som overrasker eieren av adresseplanen, er en støttehendelse som venter på en rolig uke.

Sammenligning med en separat rutet pool

Alternativet er å gi VPN-klienter sitt eget prefiks og la LAN-verter rute dit. Da sender serveren off-link-svar til gatewayen sin, gatewayen ruter prefikset til VPN-endepunktet, og det er slett ikke behov for nabo-oppløsning på LAN-segmentet. Det er færre bevegelige deler enn en lånt adresse pluss et proxysvar.

Det designet er lettere å tenke gjennom og lettere å revidere, fordi klientområdet er synlig atskilt fra LAN-området. Det koster en rute, en returvei og en tilgangsregel, de samme tingene som proxy ARP-designet trenger på et mindre åpenbart sted.

Velg bevisst mellom modellene og ikke ved uhell. proxy ARP reparerer ett bestemt forhold; en rutet pool fjerner behovet for den reparasjonen. Skriv ned hvilken du valgte og hvorfor, så slipper neste person å gjenoppdage det fra en mislykket nabooppføring.