Puxeches o enderezo VPN na lista branca e segue bloqueado? Rastréxao

Pór na lista branca o enderezo que mostra unha aplicación VPN raramente arranxa un porto bloqueado, e o paquete explica por que. A devasa non ignora a túa regra; avalia un enderezo de orixe que nada na pantalla do cliente mostra. Ata que o destino informe dese valor, cada edición da regra é unha conxectura.

Comeza pola solicitude que chega ao servizo. O enderezo do túnel, o enderezo de saída e calquera tradución entre eles seguen sendo hipóteses ata que o destino confirme unha delas.

O enderezo da aplicación non é o que chega

Unha conexión VPN leva polo menos catro enderezos que paga a pena nomear por separado: o punto final do servidor, o enderezo interno do túnel asignado ao teu cliente, o enderezo local de Wi-Fi ou Ethernet e o enderezo público que ve un sitio web despois de que o tráfico saia do provedor. Pode que a xanela do cliente só mostre o segundo. Nomea os catro antes de nomear unha regra. Con túnel dividido, as solicitudes a un destino público poden saltar o túnel por completo, así que a sesión que falla non é a que o usuario cre que iniciou.

Decide cal deses catro debe permitir a regra e despois verifícao desde o outro lado. Se o requisito é realmente un enderezo de oficina, a condición é a ruta máis a disposición de saída dese sitio, e unha conexión etiquetada como Office VPN non achega ningunha das dúas por si soa.

Percorre unha solicitude ata o seu límite de filtrado

Confirma o enderezo de destino e o porto que usa o cliente e despois comproba que este destino segue a ruta que supós. Un porto de contedor publicado, un proxy inverso ou unha redirección de porto poden trasladar a decisión a un host que nunca editaches. Cada un deses saltos pode ter a súa propia política. Establecer primeiro a ruta aforrache corrixir unha regra á que ningún paquete chega.

Nun host Linux autorizado, le as regras activas en orde antes de cambialas. Os servizos reenviados e os de contedores adoitan saltar á súa propia cadea, así que inspecciona o destino do salto e tamén o veredicto final.

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

Cita o número de regra correspondente no ticket. Sen el, o seguinte lector non pode saber que edición cambiou o resultado. Un número de regra sen marca de tempo segue sendo ambiguo.

Verifica a ruta cunha captura acoutada

Unha solicitude inocua e unha captura estreita resolven a pregunta que non deixa de reaparecer. Filtra polo porto de destino e o host investigado, limita o número de paquetes e detén a captura en canto se complete a solicitude.

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

Compara tres valores un ao lado do outro: a orixe da captura, a orixe que nomea a regra correspondente e o rexeitamento que rexistrou a aplicación. Todos poden diferir, e só o primeiro explica unha caída decidida por unha regra de IP. Unha cabeceira HTTP reenviada pertence á capa do proxy, así que un rexistro que cita esa cabeceira non describe a orixe que avaliou a devasa.

Le a orde da cadea, non só a regra

A referencia de iptables documenta o percorrido ordenado, e por iso un permiso situado baixo un rexeitamento terminal correspondente nunca rescata o paquete. Unha conexión aceptada antes tamén pode comportarse distinto dunha nova, así que un éxito antigo non di nada sobre a regra nova. Busca o rexeitamento ou a caída por riba do teu permiso antes de supor que o permiso é incorrecto. Os contadores por regra tamén che din que regra viu o paquete.

Borrar unha regra para ver que pasa é un cambio, non unha observación. Le os contadores, anota o número de regra e conserva a política orixinal no rexistro de cambios. Se unha proba é inevitable, execútaa nunha copia da cadea.

Cambia a regra que controla o seu propietario

Actualiza só a política de orixe e de servizo prevista, a través de quen a posúe. Unha saída traducida compartida pode representar moitos usuarios á vez, así que permitir ese enderezo non autentica a ninguén, e os permisos da aplicación detrás seguen onde están.

Cando o enderezo non deixa de moverse, a resposta duradeira é unha saída estable ou unha canle autenticada, non unha lista de excepcións máis longa. Anota a orixe observada, o porto de destino e o número de regra.