Por que un recurso de VPN funciona e outro queda sen tempo

Un servizo privado cárgase polo túnel e o seguinte queda sen tempo, e a tentación é reconstruír todo o perfil do cliente. O servizo que funciona é máis útil como control que como motivo para comezar de cero. Demostra que un destino, un porto e unha ruta de autorización se cumpriron, e nada máis alá.

Pódese chegar a dous servizos na mesma pasarela por familias de enderezos distintas, subredes distintas e políticas distintas.

Separe o fluxo que funciona do que falla

Trate cada servizo como o seu propio fluxo e non como un síntoma da VPN. Un cliente ilustrativo pode abrir portal.corp.example en 172.20.4.15:443 e aínda así non chegar a unha base de datos en 172.20.9.40:5432, porque son dous destinos con dous conxuntos de regras. Anote as dúas filas antes de cambiar nada, incluídos o porto e o protocolo, porque unha regra que permite TCP 443 nun host non di nada sobre TCP 5432 no mesmo host.

A fila que falla é a que hai que investigar. A fila que funciona só di onde está a liña base, e será o punto de comparación despois de cada cambio.

Compare enderezos antes de comparar nomes

Resolva cada nome completo coa política que a aplicación usa realmente e despois anote a familia de enderezos que escolleu. Un nome pode devolver un enderezo IPv6 mentres outro devolve IPv4, e unha resposta antiga na caché pode enviar unha petición a un enderezo público que non ten nada que ver co servizo privado.

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

A consulta responde a unha pregunta estreita: que ruta escollería este host para ese destino, coas táboas e regras de política actuais. Unha ruta para 172.20.4.0/24 non cobre 172.20.9.0/24, e un segundo xestor de rede ou unha ruta local con mellor especificidade poden anular o túnel en silencio. Repita a consulta dentro do espazo de nomes ou coa marca que usa a aplicación cando difiren da súa consola. Anote tamén a interface pola que sae o paquete, porque a táboa de rutas pode nomear unha interface mentres o enrutamento por política envía o fluxo por outra.

Unha ruta que coincide é unha condición necesaria, non un permiso. Dille que o paquete ten onde ir e nada sobre se un cortafuegos, un servizo de autorización ou o propio host o aceptarán.

O protocolo e a etapa de resposta din onde se detén

Unha resposta de ping non demostra que un porto de base de datos estea aberto, e unha páxina HTTPS correcta non autoriza un recurso compartido na mesma máquina. Anote que volveu realmente en lugar de aplanar cada fallo nunha soa categoría. Un tempo de espera, un reinicio, un erro de identidade TLS e un rexeitamento a nivel de aplicación apuntan cada un a unha capa distinta.

A distinción importa porque as correccións diverxen. O silencio adoita significar un problema de ruta, de cortafuegos ou de tradución no camiño. Un reinicio inmediato suxire que algo chegou ao host e rexeitou o porto. Un erro de certificado significa que a conexión chegou e o nome non coincidía, o que é un problema de configuración e non de accesibilidade. Un rexeitamento da aplicación significa que a rede fixo o seu traballo e a identidade rexeitouse despois.

Cando un recurso se publica a través dunha pasarela, compare o enderezo de orixe que ve o destino coa orixe que o seu cliente cre que usa. Unha petición orixinada pola propia pasarela pode ter éxito mentres a mesma petición desde un cliente falla, porque as dúas chegan desde enderezos distintos e atopan regras distintas.

Cambie unha variable e volva executar ambas as peticións

A identidade é o último lugar onde a xente mira e o primeiro onde aparece un rexeitamento correcto. O inicio de sesión da VPN, o grupo do directorio e a conta da aplicación son tres identidades separadas que poden divergir. O acceso a un portal nunca implica acceso á base de datos que hai detrás, e un nome nun directorio non crea unha fila noutro. Se o servizo está fóra do alcance previsto do usuario, o rexeitamento é o sistema funcionando.

Pida ao propietario do recurso que confirme o dereito previsto en lugar de engadir unha ruta ampla ou abrir un grupo como proba. Ampliar a rede para demostrar un punto é como un diagnóstico temporal se converte nunha exposición permanente, e destrúe o control co que comezou. Unha discrepancia demostrada por iteración é suficiente: unha ruta que falta, unha familia de enderezos equivocada, un porto bloqueado ou unha pertenza a grupo que falta.

Despois de cada cambio, repita ambas as peticións e manteña as saídas unha ao lado da outra. A investigación remata cando o servizo que fallaba funciona baixo a súa propia política mentres o servizo que funciona e os rexeitamentos que aínda espera se comportan exactamente como antes.