Por que unha VPN que funciona segue esgotando o tempo na resposta
Que unha petición chegue a un servidor privado é só a metade do intercambio. A súa resposta ten que atopar o cliente do túnel pola pasarela, a ruta ou a tradución previstas.
A petición chega, o servidor revístraa e o cliente segue informando dun tempo de espera esgotado. Esa combinación significa que a resposta non atopou o camiño de volta, e é un dos poucos fallos que podes confirmar desde os dous extremos á vez. Fai as comprobacións en orde e detente cando unha falle.
Comeza por onde chegou a petición
Confirma que o paquete chegou ao servizo antes de inspeccionar calquera outra cousa. Unha entrada no rexistro do servidor, un contador de conexións ou unha captura permitida no extremo remoto responden á mesma pregunta, e a súa ausencia devólvete ao túnel en lugar de levarte cara á resposta. Esta é a comprobación que separa un problema de reenvío dun problema de camiño de volta.
Se a petición nunca chegou, detente aquí. O túnel, o enrutamento cara ao prefixo privado ou a regra de acceso son o asunto, e o camiño da resposta aínda non é relevante. Anota tamén o enderezo de orixe que viu o servidor. É ou ben o enderezo do conxunto que recibiu o cliente ou un enderezo traducido, e esa diferenza determina cal das comprobacións posteriores se aplica.
A resposta necesita unha ruta cara ao conxunto
Un cliente de acceso remoto adoita recibir un enderezo dun conxunto, e a rede privada necesita unha ruta de volta cara a ese conxunto. Un servidor cuxa ruta predeterminada apunta á súa propia pasarela entrega o paquete a esa pasarela, que non ten nin idea de onde vive o conxunto, así que a resposta morre alí. O cliente ve un tempo de espera porque non volveu nada, o que é indistinguible dunha petición que nunca saíu.
Comproba a ruta que o servidor escolle para o enderezo do cliente, non a ruta que usa para a súa propia subrede. Esas dúas consultas poden dar respostas distintas, e a segunda é a que importa aquí. A tradución é o deseño alternativo e cambia o que ve o servidor. Pode simplificar un camiño de volta, e ademais elimina o enderezo orixinal do cliente dos rexistros do servidor, o que afecta a calquera regra ou informe construído sobre ese campo.
Compara a captura do servidor coa captura da pasarela
Compara o que sae do servidor co que chega á pasarela. Unha captura na interface de saída do servidor e unha captura na pasarela do túnel responden a metades distintas da pregunta, e o oco entre elas localiza a perda.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Unha petición xerada pola propia pasarela é un mal substituto dunha proba desde o cliente, porque se orixina noutro enderezo e atopa outras regras. Por iso un ping correcto desde a pasarela e unha petición fallida desde o cliente poden ser certos á vez.
Cando hai varios encamiñadores no camiño, comproba cada un que necesite unha ruta cara ao conxunto. Un deseño de sitio a sitio adoita esixir que o prefixo remoto sexa coñecido en máis dun dispositivo, e a propia pasarela ten que reenviar entre o túnel e a LAN; as notas de reenvío de strongSwan cobren a parte de sysctl e de devasa.
Anota o conxunto, o prefixo e o responsable
Na nota van catro feitos: o conxunto que recibiu o cliente, o prefixo privado que necesitaba, o encamiñador responsable da resposta e a regra de tradución se existe. Con eles, un cambio posterior de pasarela é unha comparación e non unha investigación.
Despois volve probar cun cliente corrente e coa conta real da aplicación. Ampliar os privilexios da aplicación non pode reparar o camiño de volta dun paquete, e un cambio de conta feito durante este diagnóstico confundirá a seguinte comparación. Se o deseño depende da tradución, documéntao onde se len os rexistros do servidor. Quen ve un enderezo de orixe descoñecido nunha traza de auditoría non debería ter que redescubrir a correspondencia a partir dun tícket.