Dúas LAN en NetBird: que pares encaminan e quen pode falar

Unha estación de traballo da LAN oeste abre un navegador, escribe o enderezo dunha aplicación da LAN leste e agarda ata que expira o tempo. Todas as pantallas de NetBird din que os pares están conectados, o que é certo e non vén ao caso: estar nunha rede superposta non é o mesmo que ter as dúas subredes locais nunha soa rede. O percorrido seguinte comeza nesa estación de traballo e termina cunha petición que o deseño rexeita a propósito, e cada parada é algo que se le nun dispositivo en vez de deducirse. Espere que a peza que falta sexa unha ruta ou unha política, non a superposición.

Lea o fallo primeiro desde a estación de traballo

Antes de abrir a consola de administración, estableza que envía realmente a estación de traballo. A súa propia táboa de encamiñamento decide se o paquete vai á pasarela da sede, a unha interface local ou a ningures, e esa decisión é visible sen ningunha ferramenta de superposición. Unha máquina sen ruta para o prefixo remoto fallará por moi san que pareza a lista de pares. O rango da superposición e o prefixo propio da sede son espazos de enderezos distintos, e a alta só configurou un deles.

Despois separe a resolución de nomes da conectividade, porque o navegador informa de ambas como o mesmo tempo esgotado. Repita a petición por enderezo desde unha máquina que execute o cliente NetBird e logo desde unha estación de traballo normal que non o faga. Se a máquina dada de alta ten éxito e a normal falla, a fenda está no encamiñamento local; se fallan as dúas, siga lendo antes de cambiar unha ruta.

Escolla un par de encamiñamento por sede

Un par de encamiñamento é un host que representa a súa LAN na superposición, así que escolla unha máquina Linux con conectividade estable á subrede en lugar da estación de traballo de alguén. Déao de alta polo proceso normal e póñao nun grupo co nome do rol, porque o recurso de rede e a política se referirán ambos a ese grupo. Un representante por sede segue sendo lexible; unha lexión de voluntarios anunciando o mesmo prefixo converte cada pregunta posterior nunha sesión de depuración. O enderezo do par no segmento local importa tanto como a súa identidade na superposición, porque ese enderezo convértese no seguinte salto que se indica a cada dispositivo normal.

Escriba o plan antes de tocar a consola, porque os nomes e os prefixos son onde estes deseños se desvían: prefixo, pasarela, enderezo do par e grupo, por sede. O oeste é 10.52.0.0/24 servido por 10.52.0.5 e o leste é 10.63.0.0/24 servido por 10.63.0.5; os dous grupos son west-routers e east-routers, e ningún prefixo pode solaparse co outro, co rango da superposición nin con outro destino encamiñado.

Cree o recurso, manteña a máscara

No panel despregado, cree un recurso de rede por sede e anexe a el o grupo de pares de encamiñamento desa sede. O recurso é o prefixo e o grupo é o host que responde por el, e ambos deben existir antes de que se anuncie nada. Confirme que a versión autoaloxada despregada ten o fluxo de traballo Redes, porque unha interface máis antiga cun obxecto de ruta de nome parecido é outra función.

Deixe a máscara activada. A guía de NetBird para sitio a sitio esíxea nesta disposición, e desactivala para manter visible cada enderezo orixinal non é o mesmo deseño cun salto menos; cambia o que observan as comprobacións de orixe e as políticas da superposición. A consecuencia merece dicirse sen rodeos: o servizo receptor rexistra o par de encamiñamento como orixe, non a estación de traballo individual. Se a lista de permitidos ou a auditoría dese servizo espera enderezos de estacións de traballo, ou cambia a expectativa ou a identidade debe imporse na fronteira da sede antes da tradución.

Autorice os iniciadores, non os prefixos

Unha ruta fai alcanzable un enderezo e unha política decide quen pode usalo; son dous obxectos separados con propietarios separados. Escriba a política desde a carga de traballo cara atrás: que grupo inicia, que recurso apunta e que servizo TCP necesita. Unha rede que anuncia ambos prefixos a cada par dado de alta creou alcance e non resolveu nada.

Logo lea que máis xa se permite, porque unha regra nova estreita non revoga unha ampla antiga que está por riba. Cando o leste tamén deba iniciar conexións cara ao oeste, escriba esa dirección como a súa propia política; o tráfico de retorno dunha sesión aberta polo oeste é unha pregunta distinta de permitir sesións novas cara ao leste. Se só algunhas estacións de traballo do oeste deben chegar á aplicación do leste, seleccióneas na fronteira da sede antes da tradución e manteña a autenticación propia da aplicación. O par de encamiñamento transporta o tráfico da LAN como a sede enteira e non como unha identidade de superposición por usuario, así que a contabilidade por usuario ten que vir doutro sitio.

Ensine a cada pasarela o seguinte salto e logo probe unha denegación

Os dispositivos normais nunca ven a superposición, así que a súa propia pasarela necesita unha ruta estática que apunte o prefixo remoto ao enderezo LAN do par de encamiñamento. Ese é o paso que a xente omite, porque todo o visible dentro de NetBird xa funciona mentres as estacións de traballo normais aínda expiran. A pasarela conserva a súa ruta por defecto como estaba; este prefixo é unha adición, non unha substitución.

As dúas descricións de ruta van na configuración da pasarela de cada sede, non nunha excepción no host. Ambas son rutas estáticas normais e ningunha toca a ruta por defecto:

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

Probe coa aplicación que o proxecto necesita de verdade, desde unha estación de traballo normal, e anote tres cousas: o seguinte salto elixido no lado emisor, a política que coincidiu e o enderezo de orixe que rexistrou o servizo. Probe tamén unha denegación, porque un deseño que nunca denegou nada ten bordos descoñecidos, e a denegación é a única proba de que fai o traballo a política e non o encamiñamento. Cando o leste tamén deba iniciar, comece unha conexión nova desde ese lado en lugar de supor que a segunda dirección segue. Planifique tamén o reinicio, a actualización e a substitución do par de encamiñamento, porque un host converteuse en dependencia da sede.

Os nomes privados necesitan o seu propio deseño de resolución, porque o alcance non crea rexistros DNS e un camiño IP que funciona cun nome roto lese exactamente como un camiño roto. Se un par de encamiñamento se executa dentro dunha rede de nube, revise tamén as regras de reenvío e de devasas do provedor, porque a alta non as anula. Manteña as observacións da proba xunto ao plan, porque a próxima persoa que depure isto quererá a política coincidente e o enderezo de orixe rexistrado, non unha descrición da topoloxía.