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

Klienten opretter forbindelse, modtager 10.50.0.200 og kan ikke nå serveren på 10.50.0.20, selvom begge numre ligger i samme /24. Troen bag den konfiguration er, at en adresse fra LAN-præfikset gør klienten til en del af LAN'et. Det gør den ikke. Klienten er på et punkt-til-punkt-link, serveren tror, at destinationen er lokal, og den manglende brik er et nabo-svar, som ingen sender.

Myten: samme præfiks betyder samme segment

Et adressepræfiks fortæller en vært, hvilke destinationer den kan nå direkte, og hvilke der kræver en router. Det fortæller ikke værten, hvordan destinationen fysisk er tilkoblet, og det garanterer bestemt ikke, at destinationen kan svare på en anmodning på linklaget. Det er forskellige spørgsmål, som besvares af forskellige tabeller på værten. Masken besvarer det første, og nabo-tabellen det andet, og kun det første er under din kontrol fra VPN-siden.

Når serveren sender til 10.50.0.200, sammenligner den destinationen med sin egen maske, vurderer, at adressen er on-link, og spørger det lokale segment efter den hardwareadresse, der ejer den. Den anmodning går ud på Ethernet-interfacet, og VPN-klienten er ikke der for at høre den.

Intet i klientens konfiguration kan rette det fra dens side. Svarvejen afhænger af, at en enhed på LAN'et svarer på klientens vegne, eller af at klienten har en adresse, som serveren ikke betragter som lokal.

Hvad den lokale vært faktisk gør med adressen

Adfærden er let at observere og værd at observere, før du ændrer noget. Se på nabo-tabellen på en LAN-vært, efter den har forsøgt at nå klienten: en ufuldstændig eller mislykket post er hele diagnosen på én linje. Den linje fortæller dig også, at fejlen er lokal for segmentet og ikke et sted inde 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

Ruteopslaget vil rapportere destinationen som on-link gennem Ethernet-interfacet, og det er netop problemet. Hvis naboposten forbliver ufuldstændig, mens VPN-sessionen er oppe, har du bekræftet, at den manglende brik er opløsning på linklaget og ikke routing eller firewall-politik.

Kør den samme kontrol fra en vært i et andet subnet og sammenlign. En vært, der når klienten gennem en router, har slet ikke brug for en nabopost, og den forskel er designbeslutningen i miniature.

Hvordan proxy ARP leverer et næste hop

Proxy ARP får gatewayen til at svare på anmodningen på linklaget på vegne af en destination, den kan nå gennem et andet interface. LAN-værten modtager en hardwareadresse, sender rammen til gatewayen, og gatewayen videresender pakken ind i VPN-sessionen. Fra værtens synspunkt ser klienten bare ud til at være bag gatewayen. Intet ved klientens konfiguration ændres.

MikroTiks RouterOS-ARP-dokumentation beskriver den brug for dial-in-klienter, der låner det tilsluttede LAN's adresseområde. Mekanismen er en reparation af nabo-opløsningen, og den virker, fordi gatewayen virkelig er på begge veje.

Det er ikke det samme som at bro klienten ind i LAN'et. Gatewayen skal stadig videresende pakken til den rigtige aktive session, og dens routing- og firewallpolitik skal stadig tillade tjenesten. Proxy ARP ændrer, hvem der svarer på naboanmodningen, ikke hvem der har lov til at tale.

Læs platformens tilstandsnavne omhyggeligt. RouterOS skelner mellem proxy-arp og local-proxy-arp, og den anden håndterer trafik, der kommer ind og ud ad samme interface. De er ikke udskiftelige stavemåder, og at aktivere begge uden forskel er ikke en genvej.

Hvad proxy ARP ikke giver dig

Det giver ingen broadcast- eller multicast-opdagelse. En klient, der skal finde en tjeneste via broadcast, vil stadig fejle, fordi gatewayen videresender unicast til sessionen og ikke gør klienten til medlem af LAN'ets broadcast-domæne. Opdagelsesprotokoller, der er afhængige af broadcast, er en hyppig kilde til rapporter om, at det virker til én ting og ikke til en anden, i design med lånte adresser.

Det reserverer ikke adressen. Hvis det lånte nummer også står i en DHCP-pulje eller en statisk tildeling, kan to enheder ende med den samme adresse, og den resulterende adfærd afhænger af timing. En vellykket login er ikke en reservation.

Og det fjerner ikke behovet for at koordinere med ejeren af LAN'et. En proxy ARP-post, der overrasker adresseplanens ejer, er en supporthændelse, der venter på en stille uge.

Sammenlign med en separat routet pulje

Alternativet er at give VPN-klienter deres eget præfiks og lade LAN-værter route dertil. Så sender serveren off-link-svar til sin gateway, gatewayen router præfikset til VPN-endepunktet, og der er slet ikke brug for nabo-opløsning på LAN-segmentet. Det er færre bevægelige dele end en lånt adresse plus et proxysvar.

Det design er lettere at tænke igennem og lettere at revidere, fordi klientområdet er synligt adskilt fra LAN-området. Det koster en rute, en returvej og en adgangsregel, altså de samme ting, som proxy ARP-designet har brug for et mindre oplagt sted.

Vælg bevidst mellem modellerne og ikke ved et uheld. Proxy ARP reparerer ét bestemt forhold; en routet pulje fjerner behovet for den reparation. Skriv ned, hvilken du valgte og hvorfor, så skal den næste person ikke genopdage det ud fra en mislykket nabopost.