I siti pontati hanno ancora bisogno di una decisione di uscita internet locale

L’estensione VLAN è passata pulita: gli host di entrambi i siti si vedono, le condivisioni file funzionano e le stampanti rispondono. Poi qualcuno del sito più piccolo nota che ogni download usa la linea internet dell’altro sito, e il ticket arriva come lamentela sulla banda. Il ponte ha fatto esattamente ciò che gli era stato chiesto. Trasportava frame tra due edifici e non ha mai avuto un’opinione su quale router quei frame dovessero usare per internet.

Il ponte trasporta frame, non decisioni

Un’estensione di livello 2 fa sembrare due sedi un unico dominio di broadcast, così le richieste ARP, i broadcast DHCP e il traffico della stessa sottorete attraversano tutti il tunnel. È tutto il servizio che fornisce. Nulla nel ponte ispeziona un indirizzo di destinazione, lo confronta con l’uplink di un sito o indirizza il traffico verso l’uscita più vicina. Ogni client prende ancora la propria decisione locale o remota con l’indirizzo e la maschera con cui è stato configurato.

Mettete due router su quella sottorete condivisa e entrambi diventano gateway plausibili, che uno dei due sia vicino o no al client che lo usa.

Come un client sceglie il suo gateway

La decisione IPv4 descritta in RFC 1122 è semplice. Una destinazione dentro la sottorete connessa del client si raggiunge direttamente, con ARP, e una destinazione fuori va al gateway predefinito configurato. Per questo il traffico della stessa sottorete tra i siti può attraversare il ponte senza alcun intervento del router, e per questo il traffico internet dipende interamente dall’indirizzo di gateway che il client ha ricevuto. I due comportamenti sono indipendenti, e una condivisione file funzionante dimostra solo il primo.

Se un client del sito piccolo è stato configurato con il router del sito grande, i suoi frame internet attraversano prima il tunnel ed escono da lì.

Cambiare la rotta predefinita dell’appliance VPN stessa non sposta il gateway di quel client, perché il client non usa affatto l’appliance come router. L’appliance ha anche bisogno di una rotta separata verso il suo peer remoto perché il tunnel che trasporta quei frame resti attivo, e confondere le due cose è il modo in cui un’estensione di ponte abbatte il proprio trasporto.

Lasciate che il DHCP esprima l’uscita prevista

L’opzione 3 di una risposta DHCP fornisce un elenco di indirizzi di router nella sottorete del client, in ordine di preferenza, e i client di solito prendono il primo che risponde. Il meccanismo va bene; la proprietà è dove i progetti sbagliano. Annotate cosa consegna un lease reale in ogni sito invece di supporre che il server DHCP più vicino assegni il gateway più vicino.

Gestite un allocatore coordinato, o due configurati esplicitamente per la stessa politica, e date alla politica un proprietario. Un secondo allocatore indipendente aggiunto nel sito remoto non crea località, crea due autorità per lo stesso dominio di broadcast.

Non assegnate un solo indirizzo di gateway a due router attivi in modo indipendente solo per far sembrare identiche le impostazioni dei due siti. Un indirizzo virtuale condiviso su un segmento pontato è un progetto di ridondanza del primo salto con i propri requisiti, e una versione fatta a mano produce conflitti ARP che sembrano perdite di pacchetti intermittenti. Se l’applicazione non ha davvero bisogno di un segmento di livello 2 condiviso, prefissi instradati separati con gateway predefiniti locali sono più semplici da gestire e più facili da spiegare durante un incidente.

Provate le quattro cose separatamente

Chiedete quattro osservazioni, non una. Prendete un nuovo lease DHCP in ogni sito e annotate il router e la maschera ricevuti. Raggiungete un servizio della stessa sottorete nell’altro sito e confermate che il percorso è il ponte e non una deviazione instradata. Scaricate qualcosa da internet pubblico in ogni sito e confermate quale uplink l’ha trasportato. Poi staccate il tunnel e vedete cosa si rompe, perché un sito che perde tutta la connettività quando il ponte fallisce dipendeva dal gateway remoto senza che nessuno se ne accorgesse.

Questi quattro risultati vi dicono se avete un ponte intersito, un’uscita locale o un backhaul accidentale, e raccoglierli richiede dieci minuti.

Il principio di progettazione non è glamour: il bridging decide la raggiungibilità, il DHCP decide il gateway, e la tabella di routing dell’appliance decide il percorso proprio del tunnel. Tenete i tre in conversazioni separate, perché un singolo cambiamento che cerca di sistemarli tutti di solito ne rompe due.