Conexións novas nunha saída VPN nova, os fluxos antigos déixanse tranquilos

Un drenaxe planificado só move fluxos non clasificados. Compáreo cun cambio de ruta, e vexa as marcas, as táboas e o estado de conntrack que o manteñen.

Dúas saídas VPN san, unha longa subida xa en marcha e o requisito de que a seguinte conexión use o outro túnel. Hai dúas formas de cumprilo, e só unha é segura nunha pasarela en produción. Cambiar a ruta por defecto move cada paquete, incluídos os que pertencen á subida. Un drenaxe planificado cambia a elección para as conexións novas e deixa os fluxos rastrexados na ruta na que comezaron.

Dúas formas de cambiar unha saída

O cambio de ruta é un só comando e revértese en segundos, por iso se usa durante os incidentes. Tamén é indiscriminado: os paquetes da subida existente saen de súpeto por outro túnel, con outra dirección de orixe pública e un estado de tradución á parte.

Se o extremo remoto rastrexa os fluxos por dirección de orixe, a subida pode simplemente deixar de recoñecerse. O drenaxe evítao tomando a decisión unha vez por conexión e gardándoa, así a subida antiga conserva a súa saída ata que remata. Ese é todo o valor do exercicio: o extremo remoto non ve ningún cambio que teña que interpretar. Segue recibindo paquetes que coinciden coa conexión que xa coñece.

O custo é a complexidade: dúas táboas de encamiñamento, un clasificador que se executa no gancho correcto e unhas marcas que deben coordinarse con todo o demais da máquina que as use.

Déalle a cada saída a súa propia táboa

Reserve unha táboa de encamiñamento por saída e valores de marca ou bits distintos para as dúas opcións. Cada táboa precisa as rutas axeitadas ao seu papel, non só un nome, e precisa un resultado de fallo deliberado para o caso ausente. Unha táboa baleira que cae en silencio á táboa principal é como sae o tráfico por unha saída que ninguén escolleu.

ip rule add fwmark 0x10/0x10 table 101
ip rule add fwmark 0x20/0x20 table 102
ip route add default via 192.0.2.1 dev wg-a table 101
ip route add default via 198.51.100.1 dev wg-b table 102

Engada unha ruta blackhole ao final de cada táboa para que unha busca sen coincidencia falle ruidosamente en lugar de escapar a un valor por defecto que vostede non escolleu.

Escolla unha vez, no primeiro paquete

Clasifique despois de que exista o seguimento de conexións e antes da busca de ruta que importa. Para unha conexión LAN nova e sen clasificar, escolla a saída e gárdea no estado da conexión. Nos paquetes posteriores, recupere o valor gardado na marca de paquete que le o encamiñamento por políticas.

A parte sutil é que significa novo. Conntrack aínda pode informar de NEW para paquetes temperáns e retransmisións antes de ver unha resposta, así que un clasificador que só se fixe nese estado pode sobrescribir unha elección que xa fixera. Comprobe que non haxa ningunha saída gardada para a conexión antes de asignar unha.

nftables mantén separadas as marcas de paquete e de conexión, e a guía de metainformación documenta a copia explícita entre elas. Unha marca de conexión non se converte por si soa na marca de paquete coa que coincide a súa regra, e esa é a razón máis habitual de que un clasificador ben escrito non teña efecto.

Limite a restauración á dirección e o tráfico que pretende. Aplicar unha marca de saída a internet aos paquetes que volven pode enviar as respostas cara á saída en lugar de cara á LAN, e o síntoma é unha conexión unidireccional que parece un problema de cortafuegos. Lea a ruta de resposta antes de tocar unha regra de cortafuegos, porque o paquete estase encamiñando, só que non de volta ao remitente.

Catro fases dun drenaxe

  1. Prepare B sen tocar A: encamiñamento, reenvío, autorización, NAT e a ruta de volta. Instale a súa táboa e a súa política de selección a través do propietario de configuración existente da pasarela.

  2. Cambie o clasificador para que as conexións novas e sen clasificar elixan B, conservando as eleccións gardadas. Unha transacción nftables atómica evita unha xanela na que haxa que limpar o estado antigo.

  3. Deixe A acendido mentres rematan os seus fluxos. A súa interface, táboa, saída remota e mapas NAT seguen formando parte deses fluxos, e editar unha regra NAT non reconstrúe as vinculacións que xa existen.

  4. Retire A cando se cumpra a condición de drenaxe, xulgada polo estado das conexións e o comportamento da aplicación, non por un só intervalo tranquilo.

O que un drenaxe non pode prometer

Unha petición do navegador non é unha conexión de transporte nova; a agrupación segue enviando peticións pola antiga. Á inversa, un fluxo UDP pode envellecer fóra de conntrack e un paquete posterior clasifícase de novo. O drenaxe segue os fluxos rastrexados, non a idea que unha aplicación ten dunha sesión.

Se A falla antes de que rematen os seus fluxos, a marca gardada non os salva. Reconéctanse por B, ou non se reconectan en absoluto. Un drenaxe planificado compra continuidade mentres a ruta orixinal está san; non é unha replicación de estado entre saídas independentes.

Verifique ambas as metades

Inicie unha conexión permitida de longa duración antes do cambio e outra genuinamente nova despois. Confirme que túnel usa cada unha e que dirección de orixe pública ve o extremo remoto, e logo comprobe que volve o tráfico de retorno.

Non baleire a táboa de conntrack para facer aparecer a nova elección. Iso destrúe exactamente o estado que o drenaxe debe preservar, e converte unha migración controlada nunha interrupción cunha proba de aspecto limpo.

Artigos relacionados