Brokoblede steder trenger fortsatt en beslutning om lokal internettutgang
Et delt Ethernet-segment avgjør ikke hvilken ruter en klient bruker. Skill broen fra DHCP-rutervalget og gjør utgangen på hvert sted bevisst.
VLAN-utvidelsen gikk rent gjennom: verter på begge steder ser hverandre, fildeling fungerer, og skrivere svarer. Så legger noen på det mindre stedet merke til at hver nedlasting bruker det andre stedets internettlinje, og saken kommer inn som en klage på båndbredde. Broen gjorde nøyaktig det den ble bedt om. Den fraktet rammer mellom to bygninger og hadde aldri en mening om hvilken ruter disse rammene skulle bruke til internett.
Broen bærer rammer, ikke beslutninger
En utvidelse på lag 2 får to steder til å se ut som ett kringkastingsdomene, så ARP-forespørsler, DHCP-kringkasting og trafikk i samme subnett går alle gjennom tunnelen. Det er hele tjenesten den leverer. Ingenting i broen undersøker en måladdresse, sammenligner den med et steds uplink eller styrer trafikken mot den nærmeste utgangen. Hver klient tar fortsatt sin egen lokale eller eksterne beslutning med adressen og masken den ble konfigurert med.
Sett to rutere på det delte subnettet, og begge blir plausible gatewayer, uansett om en av dem er nær klienten som bruker den.
Hvordan en klient velger gatewayen sin
IPv4-beslutningen beskrevet i RFC 1122 er enkel. En destinasjon inne i klientens tilkoblede subnett nås direkte, med ARP, og en destinasjon utenfor går til den konfigurerte standardgatewayen. Derfor kan trafikk i samme subnett mellom stedene krysse broen uten noen ruterinnblanding, og derfor avhenger internettrafikken helt av gatewayadressen klienten mottok. De to oppførslene er uavhengige, og en fungerende fildeling beviser bare den første.
Hvis en klient på det lille stedet ble konfigurert med den store stedets ruter, krysser internettrammene dens tunnelen først og går ut derfra.
Å endre VPN-enhetens egen standardrute flytter ikke den klientens gateway, fordi klienten ikke bruker enheten som ruter i det hele tatt. Enheten trenger også en egen rute til sin fjerne part for at tunnelen som bærer disse rammene skal holdes oppe, og å blande de to er hvordan en bro-utvidelse tar ned sin egen transport.
La DHCP uttrykke den tiltenkte utgangen
Alternativ 3 i et DHCP-svar gir en liste over ruteradresser på klientens subnett, i preferanserekkefølge, og klienter tar vanligvis den første som svarer. Mekanismen er fin; eierskapet er der design går galt. Noter hva en faktisk lease leverer på hvert sted i stedet for å anta at den nærmeste DHCP-serveren deler ut den nærmeste gatewayen.
Kjør én koordinert tildeler, eller to som er eksplisitt konfigurert for samme policy, og gi policyen en eier. En annen uavhengig tildeler lagt til på det fjerne stedet skaper ikke lokalitet, den skaper to myndigheter for samme kringkastingsdomene.
Ikke tildel én gatewayadresse til to uavhengig aktive rutere bare for å få innstillingene på begge stedene til å se identiske ut. En delt virtuell adresse over et brokoblet segment er et design for redundans på første hopp med egne krav, og en hjemmelaget versjon gir ARP-konflikter som ser ut som periodisk pakketap. Hvis applikasjonen ikke egentlig trenger et delt lag 2-segment, er adskilte rutede prefikser med lokale standardgatewayer enklere å drifte og lettere å forklare under en hendelse.
Test de fire tingene hver for seg
Be om fire observasjoner, ikke én. Ta en ny DHCP-lease på hvert sted og noter ruteren og masken den fikk. Nå en tjeneste i samme subnett på det andre stedet og bekreft at veien er broen og ikke en rutet omvei. Hent noe fra det offentlige internettet på hvert sted og bekreft hvilken uplink som bar det. Slipp deretter tunnelen og se hva som knekker, for et sted som mister all tilkobling når broen feiler, var avhengig av den fjerne gatewayen uten at noen la merke til det.
Disse fire resultatene forteller om du har en bro mellom stedene, en lokal utgang eller en tilfeldig bakkanal, og de tar ti minutter å samle inn.
Designprinsippet er uglamorøst: broen avgjør tilgjengelighet, DHCP avgjør gatewayen, og rutetabellen på enheten avgjør tunnelens egen vei. Hold de tre i separate samtaler, for én enkelt endring som prøver å fikse alle tre, ødelegger vanligvis to.