A comprobación de orixe/destino é unha porta, non todo o camiño VPN

A VPN remata nunha instancia de EC2, vostede pode chegar ao enderezo de túnel desa instancia, e o tráfico que debía pasar por ela cara a outro host privado desaparece. Son dúas probas distintas, e mesturalas fai perder horas. A primeira pregunta se pode chegar á instancia; a segunda pide que reenvíe tráfico para un destino que non é o seu, o que necesita reenvío de Linux, unha política de cortalumes, unha ruta no lado remoto e un permiso a nivel de AWS que non ten nada que ver co sistema operativo convidado. Nada na consola chama a atención sobre esa diferenza. O síntoma parece unha falla de encamiñamento, e normalmente non o é.

Separe as dúas probas antes de cambiar nada

Chegar á pasarela demostra o túnel, a ruta cara ao seu enderezo e o grupo de seguridade que permite o intercambio. O reenvío para outro host non demostra nada diso: usa un enderezo de orixe distinto, un destino distinto e unha instancia nun papel para o que non se construíu necesariamente. Escriba as dúas probas por separado e anote cal falla, porque a corrección de cada unha vive nunha consola distinta. Unha instancia de pasarela creada só para terminar túneis non ten motivo para reenviar nada máis, e os seus valores predeterminados reflicten iso. Por iso a segunda proba necesita a súa propia configuración en lugar dun pequeno axuste da primeira.

Un ping que funciona cara á pasarela e un ping que falla cara ao host que está máis alá non é un problema intermitente. É o comportamento esperado dunha instancia á que non se lle dixo que pode reenviar.

Escriba o camiño antes de tocar un axuste

Anote o prefixo do cliente, a instancia ou interface de rede de reenvío, a subrede de destino e a ruta de resposta. Unha entrada da táboa de rutas da VPC que apunta a unha instancia non configura o sistema operativo da instancia para reenviar, e un núcleo convidado co reenvío activado non crea unha ruta da VPC. Os dous extremos desa relación deben existir, e edítanse en lugares distintos por persoas con accesos distintos.

Despois revise o axuste de comprobación de orixe/destino no compoñente de reenvío real, non en cada instancia da VPC. AWS documenta por que unha instancia que reenvía tráfico para outros necesita esa comprobación desactivada, e tamén por que o axuste é unha decisión por instancia e non un valor predeterminado de toda a VPC.

Catro fronteiras, e a comprobación é só unha delas

Trate o camiño como catro preguntas e respóndalas en orde. A primeira resposta que falla é onde está o traballo, e ningunha das outras a compensará.

A orde importa porque comprobalo é barato: as rutas vense nunha páxina, a comprobación é un só atributo, e a opinión do destino adoita ser o último que alguén pregunta.

A tradución cambia que orixe ve o destino

Un deseño encamiñado conserva o enderezo de orixe do cliente, así que o destino necesita unha ruta de retorno ao prefixo do cliente. Un deseño traducido presenta en cambio o enderezo da pasarela, o que elimina ese requisito e substitúeo por unha táboa de estados na pasarela. Decida segundo a arquitectura que pretende, en lugar de engadir tradución porque un exemplo non relacionado a usou e pareceu funcionar.

Se traduce, limite a regra ao prefixo do cliente e ao destino previsto. Se conserva, confirme que o lado remoto realmente coñece a ruta en lugar de supoñer que aprenderá unha.

Probe desde o cliente orixinal e despois conserve o cambio

Unha solicitude xerada na pasarela pode ter éxito mentres unha solicitude reenviada falla, porque é unha orixe distinta e un caso de reenvío distinto. Tras unha corrección dirixida, repita a proba exacta de cliente a recurso que fallou, desde o mesmo cliente, e confirme que a resposta volve e non só que a solicitude chegou.

Por último, poña o axuste na configuración xestionada da pasarela para que unha instancia de substitución o reciba. Unha proba correcta que depende dunha excepción manual é unha proba que caduca na próxima reconstrución, e a persoa que a descubriu non estará alí para lembrar por que.