Hvorfor to nettsteder med samme subnett ikke er ett LAN
En vert avgjør direkte lenke kontra neste hopp før noen VPN-ruter ser pakken. To steder som deler samme prefiks trenger en utstrakt lenke eller en omnummereringsplan.
To kontorer bruker begge 192.168.77.0/24, og noen foreslår en tunnel slik at de kan være ett nettverk. Uttrykket høres enkelt ut og skjuler tre ulike design: to uavhengige LAN som kolliderer, ett bevisst Ethernet-segment strukket over en WAN, og et proxy-ARP-oppsett som svarer for eksterne adresser. Hvilket du har avgjør hva en vert gjør med pakken, og svaret er synlig før VPN-gatewayen er involvert.
Verten avgjør før ruteren
En vert med adressen 192.168.77.10/24 sammenligner målet med sitt eget prefiks. Alt innenfor dette prefikset er på direkte lenke, så verten slår opp målets lenkelagsadresse direkte. Alt utenfor går til standardgatewayen.
Den avgjørelsen skjer i vertens stakk, ikke i tunnelen. En rute lagt til på gatewayen kan ikke redde en pakke som verten aldri sender dit.
Så når 192.168.77.20 bare finnes på det andre stedet, spør den lokale verten etter det med ARP og får ikke svar. VPN-håndtrykket kan være helt sunt mens dette svikter. Feilen ser ut som en død vert og ikke som et ruteproblem. Å kjenne igjen det signalementet sparer en time med tunnelproblemløsing.
ARP er et spørsmål om den lokale lenken
ARP spør hvem som eier en adresse på denne lenken, og svaret må komme fra noe som hører kringkastingen. En ruter i den andre enden av en IPsec-tunnel hører den ikke, med mindre designet gjør de to stedene til ett kringkastingsdomene.
To enheter med samme adresse gjør det verre: selv et vellykket oppslag kan ikke si hvilken som svarte.
Dobbel adressering er ikke en rutefeil, og ingen rute retter den. Enten omnummereres stedene til forskjellige prefikser, eller de blir med vilje ett lenkelagsdomene.
Et strukket segment bærer rammer, ikke ruter
En tunnel som bærer Ethernet og er koblet til broer, gjør begge stedene til del av ett lenkelagsdomene. ARP-kringkastinger når den andre siden, og hver bro lærer hvilke MAC-adresser som ligger hvor. Linux-broens dokumentasjon beskriver den MAC-baserte videresendingsgrensen.
Her ruter den eksterne gatewayen ikke i det hele tatt mellom to identiske subnett. Rammene går gjennom et underlag som ruter IP selv, mens broene forlenger Ethernet-samtalen.
Prisen er en større påvirkningsradius. Flom mot ukjente mål, løkker, DHCP-tildeling og unik adressering krever alle én plan som favner begge stedene. Når WAN-et faller, mister verter trafikk de anser som lokal. Filtrering på broen og VLAN-regler kan begrense hva som krysser, men transporten lover fortsatt ikke at hver lokal kontrollramme kommer frem.
Proxy ARP er et tredje design
En ruter kan svare på ARP for en ekstern adresse og deretter rute mot den. Det får den eksterne verten til å se ut som om den er på direkte lenke for avsenderen uten å strekke et kringkastingsdomene.
Det er et smalere verktøy enn broing: det avhenger av videresending, returruter og en tydelig eier av hver adresse.
Det gjør heller ikke vilkårlige ikke-IP-protokoller rutbare, og det gjenskaper ikke et Ethernet-kringkastingsdomene. Bruk det når kravet er nettopp den erstatningen, ikke som en snarvei for utsatt omnummerering.
Velg ut fra kravet, og verifiser så
For vanlig applikasjonstilgang mellom kontorer gir forskjellige prefikser og eksplisitte ruter en klarere grense. Bro når kravet virkelig er lenkelagsnaboskap. Omnummerer når den eneste grunnen til det felles prefikset er at ingen har gjort det ennå.
Bekreft hvilket design du faktisk har ved å spørre en vert hva den gjør med målet:
ip route get 192.168.77.20
ip neigh show 192.168.77.20
Et resultat på direkte lenke med en mislykket nabo-oppføring peker på en manglende lenkelagsvei. Et via-resultat navngir gatewayen og flytter spørsmålet til ruting. På en bro, sjekk videresendingstabellen for å se om MAC-adressen ble lært gjennom tunnelen. Hver utskrift begrenser designspørsmålet i stedet for å starte det på nytt.