GCP Cloud VPN: comprobe a pasarela, o túnel e a devasa por orde

A súa consola mostra un túnel verde, a monitorización local segue sen alcanzar unha soa instancia, e reconstruír o túnel parece a solución obvia. Raramente o é. Un túnel establecido só demostra que dúas pasarelas remataron o intercambio IKE. Non di nada sobre se algún paquete chegou a entrar na súa VPC.

Catro decisións separan esa icona verde dunha resposta, e fallan nunha orde previsible. Abórdeas da máis barata á máis cara.

Tres obxectos, e só un deles cifra

Unha pasarela VPN posúe o enderezo externo ao que cifra o seu par. Na consola nunca a crea a man: escolla ou reserve un enderezo dentro do formulario de conexión e a pasarela aparece con el. Unha pasarela HA ocupa dous enderezos en dúas interfaces, o que importa na comprobación de cotas máis adiante.

Un túnel é o emparellamento entre esa pasarela e o par. Transporta o segredo compartido e os selectores de tráfico que promete protexer. Neses selectores comezan a maioría dos fallos silenciosos. Un túnel cuxo selector local cobre 10.0.0.0/24 non entregará 10.0.1.0/24, por moi san que pareza o estado.

O extremo remoto mantén a súa propia lista, normalmente chamada dominio de cifrado, e o hardware terminador compáraa coa súa. Ningún lado negocia un selector que nunca se lle deu.

O tipo de encamiñamento decide que chega á táboa de rutas

Cloud VPN ofrece tres formas de encamiñamento e non se mesturan limpiamente. O encamiñamento baseado en políticas conserva os pares de selectores estáticos, o encamiñamento baseado en rutas espera que vostede engada rutas estáticas, e o encamiñamento dinámico anuncia prefixos a través dun Cloud Router por BGP. Escolla un a propósito.

Un túnel dinámico con rutas estáticas escritas a man ao lado produce unha táboa de rutas que se baleira cada vez que a sesión BGP oscila.

O dinámico é a única forma que permite cambiar os prefixos protexidos sen reconstruír o túnel, e arrastra o Cloud Router ao conxunto de obxectos que debe verificar. Os selectores estáticos seguen sendo viables cando o par é unha devasa de hardware que non fala BGP. Entón ambos extremos necesitan os mesmos rangos, e a entrada máis específica debe gañar nos dous. Unha parella que discrepa nunha subrede establécese e despois transporta a metade do seu tráfico.

A denegación implícita está detrás do túnel

O tráfico de entrada avalíase contra unha denegación implícita na prioridade máis baixa, e esa regra non se preocupa de que o paquete chegase cifrado. Ata que unha regra de devasa nomee o rango local e o porto en uso, o paquete descífrase, inspecciónase e descártase. O rexistro de VPN mantense limpo en todo momento, porque o túnel fixo exactamente o que prometeu.

Lea en cambio o rexistro de denegacións da devasa cando o túnel estea activo e a sonda caduque, e logo limite unha regra ao rango de orixe e aos portos que necesita:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Que funcione unha soa dirección é unha pista da devasa

A saída compórtase distinto, porque a regra de permiso implícita deixa que as instancias envíen a calquera parte. Un centro de datos que non alcanza unha VM adoita estar detrás dun camiño de saída perfectamente funcional na outra dirección. Esa asimetría separa unha omisión de devasa dun fallo de encamiñamento, xa que un fallo de encamiñamento rompe ambas direccións á vez. Probe a dirección inversa antes de editar unha regra máis.

A creación de enderezos tamén é unha operación de cota. Un proxecto preto do seu límite de enderezos externos en uso rexeita a conexión cun erro que parece un fallo de permisos.

Selectores, cotas e logo as catro comprobacións

Os túneles creados na consola ás veces devolven un selector de tráfico remoto baleiro desde gcloud compute vpn-tunnels describe, mentres as rutas xeradas transportan o tráfico correctamente. Compare o que rexistra a API cos rangos que realmente protexe antes de decidir que o túnel está mal. Crealo mediante a API ou o SDK mantén o selector explícito.

As cotas son o outro descoido fácil. Solicite o aumento antes da ventá de mantemento e non durante ela, e comprobe o número de enderezos no mesmo proxecto que a pasarela.

Traballa de fóra cara a dentro: estado do par, ambas listas de selectores, unha ruta por lado, unha regra de entrada para o rango de orixe e o porto, e logo unha captura de paquetes. Escriba o enderezo da pasarela, ambas listas de selectores e o tipo de encamiñamento no tícket de cambio mentres o túnel é novo, porque o seguinte enxeñeiro que engada unha subrede necesitará as tres cousas.