Hvorfor to lokationer med samme subnet ikke er ét LAN

To kontorer bruger begge 192.168.77.0/24, og nogen foreslår en tunnel, så de kan være ét netværk. Sætningen lyder enkel og skjuler tre forskellige design: to uafhængige LAN, der støder sammen, ét bevidst Ethernet-segment strakt over en WAN og et proxy-ARP-arrangement, der svarer for fjerne adresser. Hvilket af dem du har, afgør, hvad en vært gør med pakken, og svaret er synligt, før VPN-gatewayen bliver involveret.

Værten afgør, før routeren gør

En vært med adressen 192.168.77.10/24 sammenligner destinationen med sit eget præfiks. Alt inden for det præfiks er på det direkte link, så værten opløser destinationens linklagsadresse direkte. Alt uden for det går til standardgatewayen.

Den beslutning sker i værtens stak, ikke i tunnelen. En rute tilføjet på gatewayen kan ikke redde en pakke, som værten aldrig sender derhen.

Så når 192.168.77.20 kun findes på den anden lokation, spørger den lokale vært efter den via ARP og får intet svar. VPN-håndtrykket kan være helt sundt, mens dette fejler. Fejlen ser ud som en død vært snarere end et ruteproblem. At genkende det fingeraftryk sparer en times tunelfejlfinding.

ARP er et spørgsmål om det lokale link

ARP spørger, hvem der ejer en adresse på dette link, og svaret skal komme fra noget, der kan høre udsendelsen. En router i den anden ende af en IPsec-tunnel hører den ikke, medmindre designet gør de to lokationer til ét broadcast-domæne.

To enheder med samme adresse gør det værre: selv en vellykket opløsning kan ikke sige, hvilken der svarede.

Dobbeltadressering er ikke en rutefejl, og ingen rute retter den. Enten omnummereres lokationerne til forskellige præfikser, eller også bliver de med vilje ét linklagsdomæne.

Et strakt segment bærer rammer, ikke ruter

En Ethernet-bærende tunnel koblet til broer gør begge lokationer til en del af ét linklagsdomæne. ARP-udsendelser når den anden side, og hver bro lærer, hvilke MAC-adresser der ligger hvor. Linux-broens dokumentation beskriver den MAC-baserede videresendelsesgrænse.

Her router den fjerne gateway slet ikke mellem to identiske subnetter. Rammer krydser et underlag, der selv router IP, mens broerne forlænger Ethernet-samtalen.

Prisen er en større radius. Flooding for ukendte destinationer, løkker, DHCP-tildeling og unik adressering kræver alle én plan, der spænder over begge lokationer. Når WAN’et falder, mister værter trafik, som de betragter som lokal. Filtrering på broen og VLAN-regler kan begrænse, hvad der krydser, men transport lover stadig ikke, at hver lokal styrelsesramme når frem.

Proxy ARP er et tredje design

En router kan svare på ARP for en fjern adresse og derefter route mod den. Det får den fjerne vært til at fremstå på det direkte link for afsenderen uden at strække et broadcast-domæne.

Det er et smallere værktøj end brobygning: det afhænger af videresendelse, returruter og en klar ejer af hver adresse.

Det gør heller ikke vilkårlige ikke-IP-protokoller rutbare, og det genskaber ikke et Ethernet-broadcast-domæne. Brug det, når kravet er præcis den substitution, ikke som en genvej til udskudt omnummerering.

Vælg ud fra kravet, og verificér så

Til almindelig applikationsadgang mellem kontorer giver forskellige præfikser og eksplicitte ruter en klarere grænse. Bro, når kravet virkelig er linklagsnaboskab. Omnummerér, når den eneste grund til det fælles præfiks er, at ingen har gjort det endnu.

Bekræft, hvilket design du faktisk har, ved at spørge en vært, hvad den gør med destinationen:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Et resultat på det direkte link med en mislykket nabo-post peger på en manglende linklagsvej. Et via-resultat navngiver gatewayen og flytter spørgsmålet til routing. På en bro skal du tjekke videresendelsesdatabasen for at se, om MAC-adressen blev lært gennem tunnelen. Hvert output indsnævrer designspørgsmålet i stedet for at genstarte det.