Pôs o endereço VPN na lista branca e continua bloqueado? Rastreie

Pôr na lista branca o endereço que uma aplicação VPN mostra raramente corrige uma porta bloqueada, e o pacote explica porquê. A firewall não está a ignorar a sua regra; está a avaliar um endereço de origem que nada no ecrã do cliente mostra. Até o destino comunicar esse valor, cada edição da regra é um palpite.

Comece pelo pedido que chega ao serviço. O endereço do túnel, o endereço de saída e qualquer tradução pelo meio continuam a ser hipóteses até o destino confirmar um deles.

O endereço na aplicação não é o que chega

Uma ligação VPN transporta pelo menos quatro endereços que vale a pena nomear em separado: o ponto final do servidor, o endereço interno do túnel atribuído ao seu cliente, o endereço local de Wi-Fi ou Ethernet e o endereço público que um site vê depois de o tráfego sair do fornecedor. A janela do cliente pode mostrar apenas o segundo. Nomeie os quatro antes de nomear uma regra. Com túnel dividido, os pedidos para um destino público podem saltar o túnel por completo, pelo que a sessão que falha não é a que o utilizador pensa ter iniciado.

Decida qual destes quatro a regra deve permitir e depois verifique-o do outro lado. Se o requisito for mesmo um endereço de escritório, a condição é a rota mais a disposição de saída desse site, e uma ligação rotulada Office VPN não fornece nenhuma das duas por si só.

Siga um pedido até à sua fronteira de filtragem

Confirme o endereço de destino e a porta que o cliente usa e depois verifique se este destino segue o caminho que assume. Uma porta de contentor publicada, um proxy inverso ou um encaminhamento de porta podem deslocar a decisão para um anfitrião que nunca editou. Cada um desses saltos pode ter a sua própria política. Estabelecer primeiro o caminho poupa-o de corrigir uma regra que nenhum pacote chega a alcançar.

Num anfitrião Linux autorizado, leia as regras ativas por ordem antes de as alterar. Os serviços encaminhados e os de contentores saltam frequentemente para a sua própria cadeia, por isso inspecione o alvo do salto e também o veredicto final.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

Cite o número da regra correspondente no ticket. Sem ele, o leitor seguinte não consegue saber que edição mudou o resultado. Um número de regra sem marca temporal continua ambíguo.

Verifique o caminho com uma captura delimitada

Um pedido inofensivo e uma captura estreita resolvem a pergunta que não deixa de reaparecer. Filtre pela porta de destino e pelo anfitrião em investigação, limite o número de pacotes e pare a captura assim que o pedido terminar.

tcpdump -ni any 'tcp dst port 9443' -c 20

Compare três valores lado a lado: a origem na captura, a origem que a regra correspondente nomeia e a rejeição que a aplicação registou. Todos podem divergir, e só o primeiro explica uma queda decidida por uma regra de IP. Um cabeçalho HTTP encaminhado pertence à camada do proxy, por isso um registo que cita esse cabeçalho não descreve a origem que a firewall avaliou.

Leia a ordem da cadeia, não só a regra

A referência do iptables documenta a passagem ordenada, e é por isso que uma permissão situada abaixo de uma rejeição terminal correspondente nunca salva o pacote. Uma ligação aceite antes também pode comportar-se de forma diferente de uma nova, pelo que um sucesso antigo nada diz sobre a regra nova. Encontre a rejeição ou a queda acima da sua permissão antes de assumir que a permissão está errada. Os contadores por regra também lhe dizem que regra viu o pacote.

Apagar uma regra para ver o que acontece é uma alteração, não uma observação. Leia os contadores, anote o número da regra e guarde a política original no registo de alterações. Se um teste for inevitável, execute-o numa cópia da cadeia.

Altere a regra que o proprietário controla

Atualize apenas a política de origem e de serviço pretendida, através de quem a detém. Uma saída traduzida partilhada pode representar muitos utilizadores ao mesmo tempo, por isso permitir esse endereço não autentica ninguém, e as permissões da aplicação por trás ficam onde estão.

Quando o endereço continua a mover-se, a resposta duradoura é uma saída estável ou um canal autenticado, não uma lista de exceções mais longa. Anote a origem observada, a porta de destino e o número da regra.