Por que o seu sensor de VPN nunca vê a etiqueta VLAN da filial
Um túnel encaminhado recupera pacotes, não as tramas que os transportaram. Quatro verificações sobre o tipo de interface, a posição do sensor, o contexto de origem e o caminho de resposta.
Um sensor do lado da VPN vê duas VLAN de filial como tráfego IP simples, e a etiqueta que identificava cada filial no seu próprio cabo desapareceu. É isso que um túnel encaminhado faz: recupera pacotes, não as tramas Ethernet que os entregaram. Se a etiqueta em falta importa depende inteiramente da pergunta que faz ao sensor. Faça as quatro verificações abaixo por ordem e saberá que ponto de observação pode responder-lhe.
Primeiro: estabeleça o que o seu túnel recupera
Uma interface TUN transporta pacotes IP, pelo que o cabeçalho VLAN da trama da filial termina no encaminhador que empurrou o tráfego para o túnel. Uma interface TAP transporta tramas Ethernet, o que significa que as etiquetas podem sobreviver quando a ponte e as regras de admissão de VLAN as deixam passar. Leia o tipo de interface antes de raciocinar sobre o que uma captura deve conter.
Nenhuma das opções é um defeito. Os dois desenhos respondem a perguntas diferentes e deixam a etiqueta em locais diferentes.
Confirme a interface você mesmo em vez de a deduzir do nome do produto. Os detalhes da ligação indicam o tipo de dispositivo e mostram os indicadores em vigor, e uma captura feita num dispositivo TUN não vai ganhar um cabeçalho Ethernet só porque a pediu. Se aparecerem etiquetas numa captura TUN, quase de certeza está a ler outra interface ou um túnel que transporta tramas dentro da sua carga útil. Anote em que caso se encontra antes de continuar.
Segundo: coloque o sensor onde o objeto ainda existe
Três posições cobrem a maioria dos desenhos encaminhados: o segmento Ethernet da filial, a rede exterior entre os extremos do túnel e o caminho após o processamento do túnel. Cada uma vê um objeto diferente, e a etiqueta só existe na primeira. Escolher uma posição de sensor é uma decisão sobre que objeto a política precisa, não uma questão de comodidade.
| Observation point | What is actually there | Question it can answer |
|---|---|---|
| Branch Ethernet segment | Tagged frames on the local wire | Which VLAN carried this frame here |
| Outer tunnel network | The protected carrier between endpoints | Which endpoints are exchanging traffic |
| After tunnel processing | Recovered IP packets | Which branch prefix the packet claims |
Coloque a pergunta de política em termos que a tabela possa responder, e normalmente resolve-se sozinha. Se a regra precisa de saber de que filial veio um pacote, o mapeamento de prefixos a jusante pode bastar, mas só enquanto esse mapeamento for exato e inequívoco. Se a regra precisa de saber em que porta chegou a trama, precisa da primeira posição, porque nada a jusante consegue reconstruí-lo. Sensores colocados por hábito em vez de por pergunta são a forma como as equipas acabam por exigir um campo que o desenho nunca transportou.
Um túnel que transporta Ethernet é um desenho diferente e precisa da sua própria verificação do que os extremos preservam ou reescrevem. Escolher TAP por si só ainda não define a ponte, as regras de admissão de VLAN nem a política de inspeção.
Terceiro: ganhe o contexto de origem em vez de confiar nele
Um intervalo de endereços por filial é o substituto habitual da identidade VLAN, e só se mantém enquanto o mapeamento continuar um para um. Prefixos sobrepostos, tradução e um gateway partilhado quebram cada um essa suposição de uma forma que parece um problema de qualidade de dados e não de desenho. Escreva o mapeamento com os seus limites e diga o que acontece a um pacote que corresponde a duas linhas. Um prefixo que aparece em duas filiais deve ser um erro que deteta, não um lançamento de moeda que aceita.
O contexto fornecido pelo cliente não é prova de pertença. É uma afirmação, e pertence a outra coluna.
Onde a distinção importa, use dados de associação que controla: que instância de túnel aceitou a ligação, em que interface chegaram os pacotes, o que diz a tabela de rotas local sobre esse par. Uma etiqueta fornecida pelo cliente é uma pista útil e uma entrada de autorização inútil. Se o sensor não conseguir estabelecer a associação do seu próprio lado, a política precisa de uma regra mais ampla e não de uma suposição confiante.
Quarto: confirme o caminho de resposta e o que a decifragem deixa passar
Um sensor que só vê uma direção ainda pode parecer saudável, porque os pedidos continuam a chegar a horas. Verifique o caminho de resposta de forma explícita, e verifique-o para o mesmo fluxo e não para a acessibilidade geral. A visibilidade de meio duplex torna-se um vazio silencioso em qualquer conclusão com estado que dela tire.
Recuperar o tráfego IP interno também não é o mesmo que ver a aplicação lá dentro, porque o TLS transportado pelo túnel continua a ser TLS.
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5
Esses dois comandos respondem à pergunta da interface e mostram o que a captura contém realmente, o que é mais rápido do que discutir a arquitetura. Substitua o nome de interface que o seu desenho usa e execute a captura enquanto o fluxo que lhe interessa está ativo. Quando não aparece nenhuma etiqueta num dispositivo TUN, a conclusão é que o desenho encaminhou em vez de fazer ponte, não que o sensor perdeu dados. Depois, ou move o sensor para uma posição que possa ver a etiqueta, ou reescreve a regra em termos que a posição atual possa sustentar.