Varför två platser med samma subnät inte är ett LAN

Två kontor använder båda 192.168.77.0/24, och någon föreslår en tunnel så att de kan vara ett nätverk. Uttrycket låter enkelt och döljer tre olika konstruktioner: två oberoende LAN som kolliderar, ett medvetet Ethernet-segment som sträcks över ett WAN, och ett proxy-ARP-upplägg som svarar för avlägsna adresser. Vilken du har avgör vad en värd gör med paketet, och svaret syns innan VPN-gatewayen är inblandad.

Värden avgör före routern

En värd med adressen 192.168.77.10/24 jämför målet med sitt eget prefix. Allt inom det prefixet ligger på direktlänken, så värden löser målets länkskiktsadress direkt. Allt utanför går till standardgatewayen.

Det beslutet fattas i värdens stack, inte i tunneln. En rutt som läggs till på gatewayen kan inte rädda ett paket som värden aldrig skickar dit.

Så när 192.168.77.20 bara finns på den andra platsen frågar den lokala värden efter det med ARP och får inget svar. VPN-handskakningen kan vara helt frisk medan detta misslyckas. Felet ser ut som en död värd och inte som ett routingproblem. Att känna igen den signaturen sparar en timme av tunnelfelsökning.

ARP är en fråga om den lokala länken

ARP frågar vem som äger en adress på den här länken, och svaret måste komma från något som hör utsändningen. En router i andra änden av en IPsec-tunnel hör den inte, om inte konstruktionen gör de två platserna till en enda utsändningsdomän.

Två enheter med samma adress gör det värre: inte ens en lyckad uppslagning kan säga vilken som svarade.

Dubbel adressering är inte ett routingfel och ingen rutt åtgärdar det. Antingen numreras platserna om till olika prefix, eller så blir de med avsikt en enda länkskiktsdomän.

Ett utsträckt segment bär ramar, inte rutter

En tunnel som bär Ethernet och är kopplad till bryggor gör båda platserna till del av en enda länkskiktsdomän. ARP-utsändningar når andra sidan, och varje brygga lär sig vilka MAC-adresser som ligger var. Dokumentationen för Linux-bryggan beskriver den MAC-baserade vidarebefordringsgränsen.

Här routar den avlägsna gatewayen inte alls mellan två identiska subnät. Ramarna går genom ett underlager som routar IP självt, medan bryggorna förlänger Ethernet-samtalet.

Priset är en större påverkansradie. Flooding mot okända mål, slingor, DHCP-tilldelning och unik adressering kräver alla en plan som omfattar båda platserna. När WAN-et faller förlorar värdar trafik som de anser vara lokal. Filtrering på bryggan och VLAN-regler kan begränsa vad som korsar, men transporten lovar fortfarande inte att varje lokal styrram kommer fram.

Proxy ARP är en tredje konstruktion

En router kan svara på ARP för en avlägsen adress och sedan routa mot den. Det får den avlägsna värden att verka ligga på direktlänken för avsändaren utan att sträcka ut en utsändningsdomän.

Det är ett smalare verktyg än bryggning: det beror på vidarebefordran, returrutter och en tydlig ägare av varje adress.

Det gör inte heller godtyckliga icke-IP-protokoll routbara, och det återskapar inte en Ethernet-utsändningsdomän. Använd det när kravet är just den substitutionen, inte som en genväg för uppskjuten omnumrering.

Välj utifrån kravet och verifiera sedan

För vanlig applikationsåtkomst mellan kontor ger olika prefix och explicita rutter en tydligare gräns. Brygga när kravet verkligen är länkskiktsgrannskap. Numrera om när den enda anledningen till det delade prefixet är att ingen har gjort det än.

Bekräfta vilken konstruktion du faktiskt har genom att fråga en värd vad den gör med målet:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Ett resultat på direktlänken med en misslyckad granne-post pekar på en saknad länkskiktsväg. Ett via-resultat namnger gatewayen och flyttar frågan till routing. På en brygga, kontrollera vidarebefordringsdatabasen för att se om MAC-adressen lärdes genom tunneln. Varje utdata snävar in konstruktionsfrågan i stället för att starta om den.