Site-urile conectate prin punte au în continuare nevoie de o decizie privind ieșirea locală în internet

Extinderea VLAN a trecut curat: gazdele din ambele site-uri se văd, partajarea fișierelor funcționează și imprimantele răspund. Apoi cineva din site-ul mai mic observă că fiecare descărcare folosește linia de internet a celuilalt site, iar tichetul ajunge ca o reclamație privind lățimea de bandă. Puntea a făcut exact ce i s-a cerut. Transporta cadre între două clădiri și nu a avut niciodată o opinie despre ce router ar trebui să folosească acele cadre pentru internet.

Puntea transportă cadre, nu decizii

O extindere de nivel 2 face două locații să arate ca un singur domeniu de difuzare, așa că cererile ARP, difuzările DHCP și traficul din aceeași subrețea traversează toate tunelul. Acesta este întregul serviciu pe care îl oferă. Nimic din punte nu inspectează o adresă de destinație, nu o compară cu legătura superioară a unui site și nu direcționează traficul către ieșirea mai apropiată. Fiecare client își ia în continuare propria decizie locală sau la distanță folosind adresa și masca cu care a fost configurat.

Puneți două routere pe acea subrețea partajată și ambele devin gateway-uri plauzibile, indiferent dacă unul dintre ele este aproape de clientul care îl folosește.

Cum își alege un client gateway-ul

Decizia IPv4 descrisă în RFC 1122 este simplă. O destinație din interiorul subrețelei conectate a clientului este atinsă direct, cu ARP, iar o destinație din afara ei merge la gateway-ul implicit configurat. De aceea traficul din aceeași subrețea între site-uri poate traversa puntea fără nicio implicare a routerului, și de aceea traficul de internet depinde în întregime de adresa de gateway pe care a primit-o clientul. Cele două comportamente sunt independente, iar o partajare de fișiere funcțională demonstrează doar primul.

Dacă un client din site-ul mic a fost configurat cu routerul site-ului mare, cadrele sale de internet traversează mai întâi tunelul și ies de acolo.

Schimbarea rutei implicite proprii a dispozitivului VPN nu mută gateway-ul acelui client, pentru că clientul nu folosește deloc dispozitivul ca router. Dispozitivul are nevoie și de o rută separată către partenerul său îndepărtat pentru ca tunelul care transportă acele cadre să rămână activ, iar confundarea celor două este modul în care o extindere de punte își dărâmă propriul transport.

Lăsați DHCP să exprime ieșirea dorită

Opțiunea 3 dintr-un răspuns DHCP furnizează o listă de adrese de router în subrețeaua clientului, în ordinea preferinței, iar clienții iau de obicei prima care răspunde. Mecanismul este în regulă; proprietatea este locul unde modelele greșesc. Notați ce livrează un lease real în fiecare site în loc să presupuneți că cel mai apropiat server DHCP va da cel mai apropiat gateway.

Rulați un alocator coordonat, sau doi configurați explicit pentru aceeași politică, și dați politicii un proprietar. Un al doilea alocator independent adăugat în site-ul îndepărtat nu creează localitate, creează două autorități pentru același domeniu de difuzare.

Nu atribuiți o singură adresă de gateway la doi routere active independent doar pentru ca setările celor două site-uri să pară identice. O adresă virtuală partajată pe un segment conectat prin punte este un proiect de redundanță la primul salt cu cerințe proprii, iar o versiune făcută manual produce conflicte ARP care arată ca pierderi intermitente de pachete. Dacă aplicația nu are într-adevăr nevoie de un segment de nivel 2 partajat, prefixe rutate separate cu gateway-uri implicite locale sunt mai simple de operat și mai ușor de explicat în timpul unui incident.

Testați cele patru lucruri separat

Cereți patru observații, nu una. Luați un lease DHCP nou în fiecare site și notați routerul și masca primite. Ajungeți la un serviciu din aceeași subrețea în celălalt site și confirmați că traseul este puntea, nu un ocol rutat. Descărcați ceva de pe internetul public în fiecare site și confirmați care legătură superioară l-a transportat. Apoi coborâți tunelul și vedeți ce se rupe, pentru că un site care pierde toată conectivitatea când puntea eșuează depindea de gateway-ul îndepărtat fără ca nimeni să observe.

Aceste patru rezultate vă spun dacă aveți o punte între site-uri, o ieșire locală sau un backhaul accidental, iar colectarea lor durează zece minute.

Principiul de proiectare nu este glamuros: puntea decide accesibilitatea, DHCP decide gateway-ul, iar tabela de rutare a dispozitivului decide calea proprie a tunelului. Țineți cele trei în conversații separate, pentru că o singură schimbare care încearcă să le repare pe toate trei de obicei strică două.