Você tem uma situação de roteamento assimétrica envolvendo NAT, aqui, e isso não vai funcionar.
Naturalmente, se sua instância de destino tiver um IP público de qualquer maneira, parece que não há muito efeito de bastião acontecendo no host do bastião ... mas supondo que você tenha um motivo lógico, aqui está minha opinião sobre o problema :
Vamos chamar a máquina cliente C , o bastion B e a instância de destino T .
O tráfego chega: IP de origem = C, IP de destino = B.
B traduz: fonte IP = C, dest IP = T. Enviar para T.
T recebe: IP de origem = C, dest IP = T.
T responde: fonte IP = T, dest IP = C.
Para onde vai o tráfego de resposta? Não para o bastião - ele vai para o Gateway da Internet ... um pacote de resposta para um fluxo TCP do qual o gateway nunca ouviu falar. O gateway, por todos os direitos, deve descartá-lo ou enviar um TCP RST para a instância de envio T para derrubar essa conexão inválida.
O cliente C não deve ver essa resposta, mas mesmo assim, o cliente agora vê ...
IP de origem = T, dest IP = C.
Isso não é esperado pelo cliente nem por nenhum firewall intermediário com estado, portanto, o tráfego é descartado ou rejeitado.
Com suas máquinas de endereçamento privado, sua rota VPC padrão (suponho) aponta para o host de bastiões, portanto não há nenhuma situação assimétrica aqui. O bastião pode traduzir os endereços na direção oposta no caminho de volta para C e tudo funciona.
Agora, teoricamente, você deve ser capaz de fazer essa configuração funcionar adicionando uma segunda regra ao bastião, para que essas conexões ssh adotem o endereço IP do bastião como seu endereço source .
Deixando a regra DNAT no lugar, você precisaria de algo assim ...
iptables -t nat -A POSTROUTING -d 10.10.9.23/32 -p tcp --dport 22 -j SNAT
Claro, eu acabei inventando isso, já que eu nunca tive a oportunidade de fazer isso ... mas a lógica, pelo menos, é boa.
Agora, supondo que isso (ou algo realmente similar) funcione, você resolveu seu problema de alcançabilidade ... e criou um novo problema: o endereço IP de origem (nos logs do servidor interno) sempre será o bastião hospedeiro. Nós não tínhamos muita escolha, mas para fazer isso, tornar a conexão traduzida roteável de volta para a Internet ... mas você pode estar melhor apenas acessando a máquina com seu endereço público.
Outra maneira de conseguir isso é com o HAProxy no bastião. O endereço de origem visto pelo servidor T ainda será o endereço interno do host do bastião ... mas agora você tem arquivos de log agradáveis no host bastion para o rastreamento do endereço IP. Na ocasião em que precisei expor um serviço TCP interno para a Internet, essa é a minha abordagem preferencial, acima de DNAT , por causa dos logs, controle de acesso e estatísticas de conexão que o proxy disponibiliza. (O HAProxy é um balanceador de carga compatível com http e um balanceador de carga TCP independente de carga. Eu não sou afiliado ao produto, apenas um fã).