TAP entrega as tramas Ethernet ao sistema operativo, o que é máis capacidade da que necesitan a maioría dos deseños de acceso remoto e menos que unha ponte. O núcleo pode enderezalo, encamiñar a través del e protexelo cun devasado sen unilo a ningún segmento físico. Vale a pena entender primeiro esa disposición: un segmento Ethernet virtual illado cuxo servidor actúa como router cara a unha LAN real. Dá comportamento de segunda capa dentro do túnel e reenvío IP ordinario fóra del, que son dúas promesas distintas. O resto é a construción, a ruta, o camiño de volta e a reversión.

Constrúe o segmento illado

En Linux a interface recibe tres ordes: créaa, actívaa e dálle un enderezo dentro do segmento que pretendes. Escolle un prefixo que non choque coa LAN da oficina e anótao, porque o choque é invisible ata que responde un host que non debería existir.

ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr add 10.77.0.1/24 dev tap0

Nada aquí require unha ponte, e nada impide engadir unha máis adiante. A documentación do núcleo sobre TUN/TAP describe a interface en si; a pertenza á ponte e a política de reenvío son decisións separadas que tomas despois.

Encamiña a través da fronteira

Activa o reenvío, permite os dous prefixos na cadea de reenvío e engade unha ruta cara ao prefixo da oficina co router da LAN como seguinte salto. O lado VPN envía entón o tráfico cara á oficina ao servidor como a súa pasarela, e o servidor reenvía eses paquetes como si mesmo, non como unha ponte. Unha interface TAP co reenvío desactivado é un segmento que responde localmente e non alcanza nada máis aló, que é o estado habitual a medio terminar. Despois comproba os contadores da interface nos dous lados, porque un contador de recepción crecente cun contador de transmisión plano no lado da LAN significa unha caída na cadea de reenvío, non unha ruta mala.

Escribe a ruta e a regra do devasado como un só cambio, porque cada unha por separado produce un estado que desde o lado do cliente parece un fallo de encamiñamento.

Decide o camiño de volta

Ou ben o router da LAN aprende unha ruta de volta ao prefixo VPN, ou ben o servidor traduce os enderezos de orixe á saída. A tradución fai trivial o camiño de volta e destrúe a identidade da orixe, así que os rexistros de destino mostrarán o enderezo do servidor para cada cliente detrás. Un prefixo encamiñado conserva a identidade e require un cambio en equipamento que quizais non xestiones.

Escolle deliberadamente e non segundo cal é máis rápido de escribir. Un só prefixo encamiñado adoita ser máis limpo ca tradución, e a tradución adoita ser mellor ca ensinar un prefixo novo a un router non xestionado para un só laboratorio.

Mantén o alcance de difusión deliberado

Dentro do segmento virtual, DHCP, o descubrimento e o anuncio de veciños compórtanse como nun conmutador, porque é unha soa ligazón. Máis aló da fronteira encamiñada non o fan, así que o DHCP da oficina e o descubrimento de servizos necesitan un deseño explícito e non a suposición de que TAP os implica. O tipo de interface non é un repetidor para servizos que viven noutro sitio.

Esa é a razón honesta para escoller TAP: algo no segmento virtual necesita comportamento local á ligazón. Se nada o necesita, un dispositivo TUN cun prefixo encamiñado é máis pequeno, e hai menos que explicar cando se rompe.

Verifica e despois escribe a reversión

Desde un cliente VPN, fai ping ao router da LAN, fai ping a un host e abre un servizo que importe por TCP. Despois comproba os contadores e a cadea de reenvío, porque unha caída por política desde lonxe parece exactamente unha ruta ausente. A reversión é o contrario da construción e pertence ao rexistro de cambios antes de comezar: retira a ruta, retira o enderezo, borra a interface.

Se o requisito é de verdade un segmento Ethernet que abrangue dous sitios, unha ponte é a resposta honesta e un deseño distinto cun radio de impacto distinto. Se o requisito é a accesibilidade, o segmento illado cun enlace ascendente encamiñado fai o traballo con menos explicacións despois.

Artigos relacionados