Ein VPN-klient med LAN-adresse er ikkje på LAN-et

Klienten koplar til, får 10.50.0.200 og når ikkje serveren på 10.50.0.20 sjølv om begge numra ligg i same /24. Trua bak den konfigurasjonen er at ei adresse frå LAN-prefikset gjer klienten til ein del av LAN-et. Det gjer ho ikkje. Klienten er på ei punkt-til-punkt-lenkje, serveren trur destinasjonen er lokal, og den manglande biten er eit nabosvar som ingen sender.

Myten: same prefiks tyder same segment

Eit adresseprefiks fortel ein vert kva destinasjonar han når direkte og kva som treng ein ruttar. Det fortel ikkje verten korleis destinasjonen er fysisk tilkopla, og det garanterer slett ikkje at destinasjonen kan svare på ein førespurnad på lenkjelaget. Det er ulike spørsmål, som blir svara av ulike tabellar på verten. Maska svarar på det første og nabotabellen på det andre, og berre det første er under din kontroll frå VPN-sida.

Når serveren sender til 10.50.0.200, samanliknar han destinasjonen med si eiga maske, vurderer at adressa er on-link, og spør det lokale segmentet etter maskinvareadressa som eig ho. Førespurnaden går ut på Ethernet-grensesnittet, og VPN-klienten er ikkje der for å høyre han.

Ingenting i konfigurasjonen til klienten kan rette dette frå sida hans. Svarvegen avheng av at eit apparat på LAN-et svarar på vegner av klienten, eller av at klienten har ei adresse som serveren ikkje ser på som lokal.

Kva den lokale verten faktisk gjer med adressa

Åtferda er lett å sjå og verdt å sjå før du endrar noko. Sjå på nabotabellen på ein LAN-vert etter at han har prøvd å nå klienten: ei ufullstendig eller mislukka oppføring er heile diagnosen på éi linje. Den linja fortel deg òg at feilen er lokal for segmentet og ikkje ein stad 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. Viss nabooppføringa blir verande ufullstendig medan VPN-økta er oppe, har du stadfesta at den manglande biten er oppløysing på lenkjelaget og ikkje ruting eller brannmurpolitikk.

Køyr den same kontrollen frå ein vert i eit anna subnett og samanlikn. Ein vert som når klienten gjennom ein ruttar treng inga nabooppføring i det heile, og den skilnaden er designavgjerda i miniatyr.

Korleis proxy ARP gjev eit neste hopp

proxy ARP får gatewayen til å svare på førespurnaden på lenkjelaget på vegner av ein destinasjon han kan nå gjennom eit anna grensesnitt. LAN-verten får ei maskinvareadresse, sender ramma til gatewayen, og gatewayen sender pakken vidare inn i VPN-økta. Frå synsstaden til verten ser klienten berre ut til å vere bak gatewayen. Ingenting ved konfigurasjonen til klienten blir endra.

MikroTiks RouterOS-ARP-dokumentasjon skildrar den bruken for dial-in-klientar som låner adresseområdet til det tilkopla LAN-et. Mekanismen er ein reparasjon av nabo-oppløysinga, og han verkar fordi gatewayen verkeleg er på begge vegar.

Det er ikkje det same som å bru klienten inn i LAN-et. Gatewayen må framleis sende pakken vidare til rett aktiv økt, og rutinga og brannmurpolitikken må framleis tillate tenesta. proxy ARP endrar kven som svarar på naboførespurnaden, ikkje kven som har lov til å snakke.

Les modusnamna til plattforma nøye. RouterOS skil mellom proxy-arp og local-proxy-arp, og den andre handterer trafikk som kjem inn og ut gjennom same grensesnitt. Dei er ikkje utskiftbare stavingar, og å slå på begge utan skilnad er inga snarveg.

Kva proxy ARP ikkje gjev deg

Det gjev inga broadcast- eller multicast-oppdaging. Ein klient som må finne ei teneste via broadcast, vil framleis mislukkast, fordi gatewayen sender unicast til økta og ikkje gjer klienten til medlem av broadcast-domenet til LAN-et. Oppdagingsprotokollar som er avhengige av broadcast, er ei vanleg kjelde til rapportar om at det verkar for éin ting og ikkje for ein annan i design med lånte adresser.

Det reserverer ikkje adressa. Viss det lånte nummeret òg står i ein DHCP-pool eller ei statisk tildeling, kan to einingar ende med same adresse, og åtferda som følgjer avheng av timing. Ei vellukka innlogging er ikkje ein reservasjon.

Og det fjernar ikkje behovet for å koordinere med eigaren av LAN-et. Ei proxy ARP-oppføring som overraskar eigaren av adresseplanen, er ei støttehending som ventar på ei roleg veke.

Samanlikning med ein separat ruta pool

Alternativet er å gje VPN-klientar sitt eige prefiks og la LAN-vertar rute dit. Då sender serveren off-link-svar til gatewayen sin, gatewayen ruter prefikset til VPN-endepunktet, og det er slett ikkje behov for nabo-oppløysing på LAN-segmentet. Det er færre bevegelege delar enn ei lånt adresse pluss eit proxysvar.

Det designet er lettare å tenkje gjennom og lettare å revidere, fordi klientområdet er synleg skilt frå LAN-området. Det kostar ei rute, ein returveg og ei tilgangsregel, dei same tinga som proxy ARP-designet treng på ein mindre openberr stad.

Vel medvite mellom modellane og ikkje ved eit uhell. proxy ARP reparerer eitt bestemt forhold; ein ruta pool fjernar behovet for den reparasjonen. Skriv ned kva du valde og kvifor, så slepp neste person å gjenoppdage det frå ei mislukka nabooppføring.