VPN encamiñada ou LAN en ponte para unha ligazón entre sucursal e laboratorio

Hai dúas formas de facer que unha sucursal chegue a un laboratorio doméstico, e a diferenza non é un axuste. Podes encamiñar entre prefixos distintos, de xeito que cada sede conserve o seu propio dominio de difusión, ou podes poñer as dúas LAN en ponte nunha soa, de xeito que as difusións e o tráfico de descubrimento se comporten coma se todos estivesen na mesma sala. O encamiñamento é o deseño que sobrevive ao contacto cunha rede real. A ponte é o deseño que fai fácil a primeira semana e interesante a primeira avaría. A comparación de abaixo trata do que cada un che dá e do que custa, seguida de como facer comprobable a versión encamiñada.

Dúas formas de conectar, un compromiso evidente

Unha ligazón encamiñada trata o laboratorio doméstico como unha rede remota co seu propio enderezo. A sucursal pide o prefixo do laboratorio, o túnel transporta eses paquetes e a porta de enlace do laboratorio responde desde a súa propia subrede. Nada da táboa ARP da sucursal cambia, e nada do ámbito DHCP do laboratorio chega á sucursal.

Unha ligazón en ponte estende un único dominio de capa 2 polas dúas sedes. Os protocolos de descubrimento funcionan, os dispositivos aparecen automaticamente, e cada difusión, cada solicitude ARP e cada paquete multicast é agora un candidato a cruzar o túnel, é dicir, unha gran cantidade de tráfico transportada por protocolos deseñados para un segmento local e non para unha WAN con outra MTU e un tempo de ida e volta variable.

O que che dá o encamiñamento

O primeiro beneficio é o raio do dano. Un bucle, un servidor DHCP indesexado ou unha inundación de difusións queda na sede que o produciu, porque un encamiñador non reenvía difusións. O segundo é a claridade do enderezo: o prefixo da sucursal e o do laboratorio son distintos, así que o destino dun paquete dixe que sede debe responder, e unha regra de cortalumes pode dicir «sucursal a subrede do laboratorio» en lugar de «calquera sitio a calquera sitio».

O terceiro é que encaixa co que o túnel transporta de verdade. Unha política IPsec é un par de prefixos, e a ruta de reenvío de cada lado é encamiñamento IP corrente co reenvío activado na porta de enlace:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

O que cedes é o descubrimento por difusión. É unha perda real, e debe substituírse a propósito en lugar de sortearse poñéndoo todo en ponte.

O que custa a ponte

A ponte ten que levar tramas de capa 2 por un túnel, o que implica unha encapsulación como GRE ou VXLAN sobre IPsec en vez dun túnel simple baseado en políticas. Unha vez que existe, as dúas sedes comparten un dominio de fallo. A árbore de expansión ve o túnel como unha ligazón, o tráfico de difusión consome ancho de banda do túnel, e calquera dispositivo que supón un segmento de baixa latencia compórtase mal de formas difíciles de atribuír desde calquera dos extremos.

Tamén elimina a comprobación de enderezo que te mantén honesto. Cun prefixo plano, un enderezo duplicado non é un erro de encamiñamento senón dous anfitrións que se rouban o tráfico en silencio, e os prefixos solapados entre unha sucursal e un laboratorio son habituais en montaxes de laboratorio doméstico, así que a ponte non resolve ese conflito; repárteo.

O argumento de seguridade é o que adoita decidilo. Unha ponte estende o segmento no que operan os protocolos de ligazón local, así que un dispositivo na sucursal pode falar con dispositivos do laboratorio que nunca deberían ser accesibles desde fóra. Se o laboratorio ten un hipervisor, unha consola de almacenamento e unha interface de xestión na mesma rede plana, agora iso é un só segmento xunto coa sucursal.

Nomes sen difusión

A razón pola que a xente pon en ponte adoita ser o descubrimento: unha impresora, un reprodutor multimedia ou un anfitrión do laboratorio que nunca aparece nunha lista. A resposta encamiñada é un servizo de nomes. Publica os anfitrións do laboratorio nunha zona que o resolvedor da sucursal poida alcanzar, e despois deixa que os usuarios se conecten por nome en lugar de explorar a rede. Iso é máis traballo ao principio e bastante menos traballo en cada cambio futuro.

O descubrimento multicast é o caso máis difícil, e merece precisión. Protocolos como mDNS usan multicast de ligazón local, que os encamiñadores non reenvían de forma predeterminada, así que un anfitrión do laboratorio ausente dunha lista de descubrimento pode seguir sendo accesible no seu enderezo documentado. Se un servizo concreto esixe de verdade multicast, planifica ese único protocolo, cun reflector ou unha regra de reenvío dirixida, en lugar de poñer toda a LAN en ponte como reparación xeral.

Un reflector tampouco é unha vitoria gratis. Importa o mesmo tráfico falangueiro que intentabas evitar, un servizo de cada vez, e necesita un dono que note cando un dispositivo comeza a anunciar máis que antes. Escólleo por servizo, e escribe por que. Anota que servizo o necesitaba e que anuncia, porque unha actualización de firmware pode cambiar esa lista sen avisar a ninguén.

Fai comprobable o deseño encamiñado

Escolle un obxectivo, por exemplo unha interface web do laboratorio na súa propia subrede de servidores, e demóstrao nos dous sentidos. Desde un anfitrión da sucursal, confirma o enderezo e o servizo á escoita en local, despois conéctate polo túnel e repite. Un túnel que está erguido demostra que as portas de enlace están de acordo; non demostra nada sobre o cortalumes do anfitrión nin sobre a ruta de retorno.

A porta de enlace normal do laboratorio necesita unha ruta de volta ao prefixo da sucursal, agás que o deseño traduza a orixe a propósito, e o cortalumes do propio servidor ten que aceptar o rango remoto permitido. Ningunha das dúas cousas configúraa un túnel correcto. As notas de reenvío de strongSwan describen a ruta dos paquetes que debe funcionar en cada lado.

Despois proba tamén un destino denegado. Un usuario da sucursal que precisa unha aplicación non precisa a consola do hipervisor, e a única forma de saber que a política é real é probar xusto o que debería rexeitar. Anota os prefixos, a dependencia do resolvedor e os resultados das probas, e un cambio futuro en calquera das dúas sedes pódese revisar en minutos en lugar de reconstruírse de memoria.