Kvifor to nettstader med same subnett ikkje er eitt LAN
Ein vert avgjer direkte lenkje kontra neste hopp før nokon VPN-rutar ser pakken. To stader som deler same prefiks treng ei utstrekt lenkje eller ein omnummereringsplan.
To kontor brukar begge 192.168.77.0/24, og nokon føreslår ein tunnel slik at dei kan vere eitt nettverk. Uttrykket høyrest enkelt ut og skjuler tre ulike design: to uavhengige LAN som kolliderer, eitt medvite Ethernet-segment strekt over ein WAN, og eit proxy-ARP-oppsett som svarar for eksterne adresser. Kva du har avgjer kva ein vert gjer med pakken, og svaret er synleg før VPN-gatewayen er involvert.
Vertenen avgjer før rutaren
Ein vert med adressa 192.168.77.10/24 samanliknar målet med sin eigen prefiks. Alt innanfor denne prefiksen er på direkte lenkje, så verten slår opp lenkjelagsadressa til målet direkte. Alt utanfor går til standardgatewayen.
Den avgjerda skjer i stakken til verten, ikkje i tunnelen. Ei rute lagt til på gatewayen kan ikkje redde ein pakke som verten aldri sender dit.
Så når 192.168.77.20 berre finst på den andre staden, spør den lokale verten etter det med ARP og får ikkje svar. VPN-handtrykket kan vere heilt sunt medan dette sviktar. Feilen ser ut som ein død vert og ikkje som eit ruteproblem. Å kjenne att det signalementet sparer ein time med tunnelproblemløysing.
ARP er eit spørsmål om den lokale lenkja
ARP spør kven som eig ei adresse på denne lenkja, og svaret må kome frå noko som høyrer kringkastinga. Ein rutar i den andre enden av ein IPsec-tunnel høyrer den ikkje, med mindre designet gjer dei to stadene til eitt kringkastingsdomene.
To einingar med same adresse gjer det verre: sjølv eit vellukka oppslag kan ikkje seie kven som svara.
Dobbel adressering er ikkje ein rutefeil, og inga rute rettar den. Anten blir stadene omnummererte til ulike prefiks, eller dei blir med vilje eitt lenkjelagsdomene.
Eit strekt segment ber rammer, ikkje ruter
Ein tunnel som ber Ethernet og er kopla til bruer, gjer begge stadene til del av eitt lenkjelagsdomene. ARP-kringkastingar når den andre sida, og kvar bru lærer kva MAC-adresser som ligg kvar. Dokumentasjonen til Linux-brua skildrar den MAC-baserte videresendingsgrensa.
Her rutar den eksterne gatewayen slett ikkje mellom to identiske subnett. Rammene går gjennom eit underlag som rutar IP sjølv, medan bruene forlenger Ethernet-samtalen.
Prisen er ein større påverknadsradius. Flaum mot ukjende mål, løkker, DHCP-tildeling og unik adressering krev alle éin plan som femner begge stadene. Når WAN-et fell, mistar vertar trafikk dei reknar som lokal. Filtrering på brua og VLAN-reglar kan avgrense kva som kryssar, men transporten lovar framleis ikkje at kvar lokal kontrollramme kjem fram.
Proxy ARP er eit tredje design
Ein rutar kan svare på ARP for ei ekstern adresse og deretter rute mot den. Det får den eksterne verten til å sjå ut som om han er på direkte lenkje for avsendaren utan å strekke eit kringkastingsdomene.
Det er eit smalare verktøy enn bruing: det avheng av videresending, returruter og ein tydeleg eigar av kvar adresse.
Det gjer heller ikkje vilkårlege ikkje-IP-protokollar rutbare, og det attskapar ikkje eit Ethernet-kringkastingsdomene. Bruk det når kravet er nettopp den erstatninga, ikkje som ein snarvveg for utsett omnummerering.
Vel ut frå kravet, og verifiser så
For vanleg applikasjonstilgang mellom kontor gir ulike prefiks og eksplisitte ruter ei klarare grense. Bru når kravet verkeleg er lenkjelagsnaboskap. Omnummerer når den einaste grunnen til det felles prefikset er at ingen har gjort det enno.
Stadfest kva design du faktisk har ved å spørje ein vert kva han gjer med målet:
ip route get 192.168.77.20
ip neigh show 192.168.77.20
Eit resultat på direkte lenkje med ein mislukka nabo-oppføring peikar på ein manglande lenkjelagsveg. Eit via-resultat namngir gatewayen og flyttar spørsmålet til ruting. På ei bru, sjekk videresendingstabellen for å sjå om MAC-adressa vart lært gjennom tunnelen. Kvar utskrift avgrensar designspørsmålet i staden for å starte det på nytt.