Due LAN su NetBird: quali peer instradano e chi può parlare

Una workstation sulla LAN ovest apre un browser, digita l'indirizzo di un'applicazione sulla LAN est e attende fino allo scadere del tempo. Ogni schermata di NetBird dice che i peer sono connessi, il che è vero e fuori tema: stare in una rete overlay non è lo stesso che avere le due sottoreti locali in un'unica rete. Il percorso seguente parte da quella workstation e termina con una richiesta che il progetto rifiuta di proposito, e ogni tappa è qualcosa che si legge da un dispositivo invece di indovinarlo. Aspettati che il pezzo mancante sia una rotta o una policy, non l'overlay.

Leggi prima il guasto dalla workstation

Prima di aprire la console di gestione, stabilisci cosa invia davvero la workstation. La sua tabella di instradamento decide se il pacchetto va al gateway del sito, a un'interfaccia locale o da nessuna parte, e quella decisione è visibile senza alcuno strumento overlay. Una macchina senza rotta per il prefisso remoto fallirà, per quanto sana sembri la lista dei peer. L'intervallo overlay e il prefisso del sito sono spazi di indirizzi diversi, e l'iscrizione ne ha configurato solo uno.

Poi separa la risoluzione dei nomi dalla raggiungibilità, perché il browser segnala entrambe come lo stesso timeout. Ripeti la richiesta per indirizzo da una macchina che esegue il client NetBird, poi da una workstation normale che non lo esegue. Se la macchina iscritta riesce e quella normale fallisce, il divario è nell'instradamento locale; se falliscono entrambe, continua a leggere prima di cambiare una rotta.

Scegli un peer di instradamento per sito

Un peer di instradamento è un host che rappresenta la propria LAN sull'overlay, quindi scegli una macchina Linux con raggiungibilità stabile alla sottorete invece della workstation di scrivania di qualcuno. Iscrívila con il processo normale e mettila in un gruppo chiamato come il ruolo, perché la risorsa di rete e la policy faranno entrambe riferimento a quel gruppo. Un rappresentante per sito resta leggibile; una frotta di volontari che annunciano lo stesso prefisso trasforma ogni domanda successiva in una sessione di debug. L'indirizzo del peer sul segmento locale conta quanto la sua identità sull'overlay, perché quell'indirizzo diventa il salto successivo che viene detto a ogni dispositivo normale.

Scrivi il piano prima di toccare la console, perché nomi e prefissi sono il punto in cui questi progetti deragliano: prefisso, gateway, indirizzo del peer e gruppo, per sito. L'ovest è 10.52.0.0/24 servito da 10.52.0.5 e l'est è 10.63.0.0/24 servito da 10.63.0.5; i due gruppi sono west-routers ed east-routers, e nessun prefisso può sovrapporsi all'altro, all'intervallo overlay o a un'altra destinazione instradata.

Crea la risorsa, tieni attivo il mascheramento

Nella dashboard distribuita, crea una risorsa di rete per sito e collegale il gruppo dei peer di instradamento di quel sito. La risorsa è il prefisso e il gruppo è l'host che risponde per esso, ed entrambi devono esistere prima che qualcosa venga annunciato. Verifica che la versione self-hosted distribuita abbia davvero il flusso di lavoro Reti, perché un'interfaccia più vecchia con un oggetto rotta dal nome simile è un'altra funzione.

Lascia attivo il mascheramento. La guida di NetBird da sito a sito lo richiede in questa disposizione, e disattivarlo per mantenere visibile ogni indirizzo originale non è lo stesso progetto con un salto in meno; cambia ciò che vedono i controlli di origine e le policy dell'overlay. La conseguenza va detta chiaramente: il servizio ricevente registra il peer di instradamento come origine, non la singola workstation. Se la lista di autorizzati o l'audit di quel servizio si aspetta indirizzi di workstation, o cambia l'aspettativa o l'identità deve essere imposta al confine del sito prima della traduzione.

Autorizza gli iniziatori, non i prefissi

Una rotta rende raggiungibile un indirizzo e una policy decide chi può usarlo; sono due oggetti separati con proprietari separati. Scrivi la policy a rovescio dal carico di lavoro: quale gruppo inizia, quale risorsa punta e quale servizio TCP richiede. Una rete che annuncia entrambi i prefissi a ogni peer iscritto ha creato raggiungibilità e non ha risolto nulla.

Poi leggi cos'altro è già permesso, perché una nuova regola stretta non revoca una vecchia larga che le sta sopra. Quando anche l'est deve iniziare connessioni verso ovest, scrivi quella direzione come policy a sé; il traffico di ritorno di una sessione aperta da ovest è una domanda diversa dal consentire nuove sessioni verso est. Se solo alcune workstation ovest devono raggiungere l'applicazione est, selezionale al confine del sito prima della traduzione e mantieni l'autenticazione propria dell'applicazione. Il peer di instradamento trasporta il traffico LAN come il sito intero e non come identità overlay per utente, quindi la contabilità per utente deve venire da altrove.

Insegna a ogni gateway il salto successivo, poi prova un rifiuto

I dispositivi normali non vedono mai l'overlay, quindi il loro gateway ha bisogno di una rotta statica che punti il prefisso remoto all'indirizzo LAN del peer di instradamento. È il passo che la gente salta, perché tutto ciò che è visibile dentro NetBird funziona già mentre le workstation normali scadono ancora. Il gateway conserva la rotta predefinita com'era; questo prefisso è un'aggiunta, non una sostituzione.

Le due descrizioni di rotta vanno nella configurazione del gateway di ciascun sito, non in una sovrascrittura sull'host. Entrambe sono normali rotte statiche e nessuna tocca la rotta predefinita:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Prova con l'applicazione di cui il progetto ha davvero bisogno, da una workstation normale, e annota tre cose: il salto successivo scelto lato mittente, la policy che ha corrisposto e l'indirizzo di origine che il servizio ha registrato. Prova anche un rifiuto, perché un progetto che non ha mai rifiutato nulla ha bordi sconosciuti, e il rifiuto è l'unica prova che fa il lavoro la policy e non l'instradamento. Quando anche l'est deve iniziare, avvia una nuova connessione da quel lato invece di supporre che la seconda direzione segua. Pianifica anche riavvio, aggiornamento e sostituzione del peer di instradamento, perché un host è diventato una dipendenza del sito.

I nomi privati hanno bisogno del proprio progetto di resolver, perché la raggiungibilità non crea record DNS e un percorso IP funzionante con un nome rotto si legge esattamente come un percorso rotto. Se un peer di instradamento gira dentro una rete cloud, esamina anche le regole di inoltro e del firewall del provider, perché l'iscrizione non le annulla. Tieni le osservazioni del test accanto al piano, perché la prossima persona che lo depurerà vorrà la policy corrispondente e l'indirizzo di origine registrato, non una descrizione della topologia.