Brulaga stader treng framleis ei avgjerd om lokal internetutgang

VLAN-utvidinga gjekk reint gjennom: vertar på begge stadene ser kvarandre, fildeling fungerer og skrivarar svarar. Så legg nokon på den mindre staden merke til at kvar nedlasting brukar internettlinja til den andre staden, og saka kjem inn som ei klage på bandbreidde. Brua gjorde nøyaktig det ho vart beden om. Ho frakta rammer mellom to bygningar og hadde aldri ei meining om kva ruter desse rammene skulle bruke til internett.

Brua ber rammer, ikkje avgjerder

Ei utviding på lag 2 får to stader til å sjå ut som eitt kringkastingsdomene, så ARP-førespurnader, DHCP-kringkasting og trafikk i same subnett går alle gjennom tunnelen. Det er heile tenesta ho leverer. Ingenting i brua granskar ei måladresse, samanliknar ho med uplinken til ein stad eller styrer trafikken mot den næraste utgangen. Kvar klient tek framleis si eiga lokale eller eksterne avgjerd med adressa og maska han vart konfigurert med.

Set to rutarar på det delte subnettet, og begge vert trulege gatewayar, same om ein av dei er nær klienten som brukar han.

Korleis ein klient vel gatewayen sin

IPv4-avgjerda som er skildra i RFC 1122 er enkel. Ein destinasjon inne i det tilkopla subnettet til klienten vert nådd direkte, med ARP, og ein destinasjon utanfor går til den konfigurerte standardgatewayen. Derfor kan trafikk i same subnett mellom stadene krysse brua utan noka ruterinnblanding, og derfor avheng internettrafikken heilt av gatewayadressa klienten fekk. Dei to åtferdene er uavhengige, og ei fungerande fildeling beviser berre den første.

Om ein klient på den litle staden vart konfigurert med ruteren til den store staden, kryssar internettrammene hans tunnelen først og går ut derifrå.

Å endre den eigne standardruta til VPN-eininga flyttar ikkje gatewayen til den klienten, fordi klienten ikkje brukar eininga som ruter i det heile. Eininga treng også ei eiga rute til sin fjerne part for at tunnelen som ber desse rammene skal halde seg oppe, og å blande dei to er korleis ei bruutviding tek ned sin eigen transport.

Lat DHCP uttrykke den tiltenkte utgangen

Val 3 i eit DHCP-svar gjev ei liste over ruteradresser på subnettet til klienten, i preferanserekkjefølgje, og klientar tek vanlegvis den første som svarar. Mekanismen er fin; eigarskapet er der design går gale. Noter kva ein faktisk lease gjev på kvar stad i staden for å tru at den næraste DHCP-tenaren deler ut den næraste gatewayen.

Køyr éin koordinert tildelar, eller to som er eksplisitt konfigurerte for same politikk, og gje politikken ein eigar. Ein annan uavhengig tildelar lagd til på den fjerne staden skapar ikkje lokalitet, han skapar to styresmakter for same kringkastingsdomene.

Ikkje tildel éi gatewayadresse til to uavhengig aktive rutarar berre for å få innstillingane på begge stadene til å sjå identiske ut. Ei delt virtuell adresse over eit brulaga segment er eit design for redundans på første hopp med eigne krav, og ein heimelaga versjon gjev ARP-konfliktar som ser ut som periodisk pakketap. Om applikasjonen ikkje eigentleg treng eit delt lag 2-segment, er åtskilde ruta prefiks med lokale standardgatewayar enklare å drive og lettare å forklare under ei hending.

Test dei fire tinga kvar for seg

Be om fire observasjonar, ikkje éin. Tak ein ny DHCP-lease på kvar stad og noter ruteren og maska han fekk. Nå ein teneste i same subnett på den andre staden og stadfest at vegen er brua og ikkje ein ruta omveg. Hent noko frå det opne internettet på kvar stad og stadfest kva uplink som bar det. Slepp så tunnelen og sjå kva som knekk, for ein stad som mistar all tilkopling når brua sviktar, var avhengig av den fjerne gatewayen utan at nokon la merke til det.

Dei fire resultata fortel om du har ei bru mellom stadene, ein lokal utgang eller ein tilfeldig bakkanal, og dei tek ti minutt å samle inn.

Designprinsippet er uglamorøst: brua avgjer tilgjenge, DHCP avgjer gatewayen, og rutetabellen på eininga avgjer den eigen vegen til tunnelen. Hald dei tre i separate samtalar, for éi endring som prøver å rette alle tre, øydelegg vanlegvis to.