En VPN-klient med LAN-adress är inte på LAN-et

Klienten ansluter, får 10.50.0.200 och kan inte nå servern på 10.50.0.20 trots att båda numren ligger i samma /24. Tron bakom den konfigurationen är att en adress från LAN-prefixet gör klienten till en del av LAN-et. Det gör den inte. Klienten är på en punkt-till-punkt-länk, servern anser att destinationen är lokal, och den saknade biten är ett grannsvar som ingen skickar.

Myten: samma prefix betyder samma segment

Ett adressprefix talar om för en värd vilka destinationer den når direkt och vilka som behöver en router. Det talar inte om för värden hur destinationen är fysiskt ansluten, och det garanterar absolut inte att destinationen kan svara på en förfrågan på länklagret. Det är olika frågor, som besvaras av olika tabeller på värden. Masken besvarar den första och grann-tabellen den andra, och bara den första är under din kontroll från VPN-sidan.

När servern skickar till 10.50.0.200 jämför den destinationen med sin egen mask, bedömer att adressen är on-link och frågar det lokala segmentet efter den hårdvaruadress som äger den. Den förfrågan går ut på Ethernet-gränssnittet, och VPN-klienten är inte där för att höra den.

Ingenting i klientens konfiguration kan rätta detta från dess sida. Svarsvägen beror på att en enhet på LAN-et svarar å klientens vägnar, eller på att klienten har en adress som servern inte anser vara lokal.

Vad den lokala värden faktiskt gör med adressen

Beteendet är lätt att observera och värt att observera innan du ändrar något. Titta på grann-tabellen på en LAN-värd efter att den har försökt nå klienten: en ofullständig eller misslyckad post är hela diagnosen på en rad. Den raden säger också att felet är lokalt för segmentet och inte någonstans inne i tunneln.

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

Rutuppslagningen kommer att rapportera destinationen som on-link genom Ethernet-gränssnittet, och det är precis problemet. Om grannposten förblir ofullständig medan VPN-sessionen är uppe har du bekräftat att den saknade biten är upplösning på länklagret och inte routing eller brandväggspolicy.

Kör samma kontroll från en värd i ett annat subnät och jämför. En värd som når klienten genom en router behöver ingen grannpost alls, och den skillnaden är designbeslutet i miniatyr.

Hur proxy ARP ger ett nästa hopp

proxy ARP får gatewayen att svara på förfrågan på länklagret å en destinations vägnar som den kan nå genom ett annat gränssnitt. LAN-värden tar emot en hårdvaruadress, skickar ramen till gatewayen, och gatewayen vidarebefordrar paketet in i VPN-sessionen. Från värdens synvinkel ser klienten bara ut att vara bakom gatewayen. Ingenting i klientens konfiguration ändras.

MikroTiks RouterOS ARP-dokumentation beskriver den användningen för dial-in-klienter som lånar det anslutna LAN-ets adressutrymme. Mekanismen är en reparation av grannupplösningen, och den fungerar eftersom gatewayen verkligen är på båda vägarna.

Det är inte samma sak som att broa klienten in i LAN-et. Gatewayen måste fortfarande vidarebefordra paketet till rätt aktiv session, och dess routing och brandväggspolicy måste fortfarande tillåta tjänsten. proxy ARP ändrar vem som svarar på grannförfrågan, inte vem som får tala.

Läs plattformens lägesnamn noga. RouterOS skiljer mellan proxy-arp och local-proxy-arp, och den andra hanterar trafik som kommer in och ut genom samma gränssnitt. De är inte utbytbara stavningar, och att aktivera båda utan urskillning är ingen genväg.

Vad proxy ARP inte ger dig

Det ger ingen broadcast- eller multicast-upptäckt. En klient som måste hitta en tjänst via broadcast kommer fortfarande att misslyckas, eftersom gatewayen vidarebefordrar unicast till sessionen och inte gör klienten till medlem i LAN-ets broadcast-domän. Upptäcktsprotokoll som förlitar sig på broadcast är en vanlig källa till rapporter om att det fungerar för en sak och inte för en annan i designer med lånade adresser.

Det reserverar inte adressen. Om det lånade numret också finns i en DHCP-pool eller en statisk tilldelning kan två enheter hamna med samma adress, och beteendet som följer beror på timing. En lyckad inloggning är inte en reservation.

Och det tar inte bort behovet av att samordna med ägaren av LAN-et. En proxy ARP-post som överraskar ägaren av adressplanen är en supportincident som väntar på en lugn vecka.

Jämförelse med en separat routad pool

Alternativet är att ge VPN-klienter sitt eget prefix och låta LAN-värdar routa dit. Då skickar servern off-link-svar till sin gateway, gatewayen routar prefixet till VPN-slutpunkten, och det behövs alls ingen grannupplösning på LAN-segmentet. Det är färre rörliga delar än en lånad adress plus ett proxysvar.

Den designen är lättare att tänka igenom och lättare att granska, eftersom klientintervallet är synligt åtskilt från LAN-intervallet. Det kostar en rutt, en returväg och en åtkomstregel, samma saker som proxy ARP-designen behöver på en mindre uppenbar plats.

Välj medvetet mellan modellerna och inte av misstag. proxy ARP reparerar en specifik relation; en routad pool tar bort behovet av den reparationen. Skriv ner vilken du valde och varför, så behöver nästa person inte upptäcka det igen från en misslyckad grannpost.