Porta SSH VPC em frente em sub-rede privada

3

Ok, então eu estive quebrando meu cérebro por DAYS neste dilema. Eu tenho uma configuração de VPC com uma sub-rede pública e uma sub-rede privada. O NAT está no lugar do curso. Eu posso conectar a partir de SSH em uma instância na sub-rede pública, bem como o NAT. Eu posso até mesmo conectar-se à instância privada da instância pública. Alterei a configuração do SSHD na instância privada para aceitar a porta 22 e um número de porta arbitrário 1300. Isso funciona bem.

Mas eu preciso configurá-lo para que eu possa se conectar à instância privada diretamente usando o número da porta 1300, ou seja,

ssh -i keyfile.pem [email protected] -p 1300

e 1.2.3.4 devem rotea-lo para o servidor interno 10.10.10.10.

Agora eu ouvi que iptables é o trabalho para isso, então eu fui em frente e pesquisei e brinquei com algum roteamento com isso. Estas são as regras que eu configurei na instância pública (não no NAT). Eu não queria usar o NAT para isso, pois a AWS pré-configura as instâncias do NAT quando você as configura e ouvi que usar o iptables pode atrapalhar isso.

*filter
:INPUT ACCEPT [129:12186]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [84:10472]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 1300 -j ACCEPT
-A INPUT -d 10.10.10.10/32 -p tcp -m limit --limit 5/min -j LOG --log-prefix "SSH Dropped: "
-A FORWARD -d 10.10.10.10/32 -p tcp -m tcp --dport 1300 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Wed Apr 17 04:19:29 2013
# Generated by iptables-save v1.4.12 on Wed Apr 17 04:19:29 2013
*nat
:PREROUTING ACCEPT [2:104]
:INPUT ACCEPT [2:104]
:OUTPUT ACCEPT [6:681]
:POSTROUTING ACCEPT [7:745]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 1300 -j DNAT --to-destination 10.10.10.10:1300
-A POSTROUTING -p tcp -m tcp --dport 1300 -j MASQUERADE
COMMIT

Então, quando eu tento isso em casa. Apenas expira. Nenhuma conexão recusou mensagens ou qualquer coisa. E não consigo encontrar nenhuma mensagem de log sobre pacotes descartados.

Meus grupos de segurança e configurações de ACL permitem a comunicação nessas portas em ambas as direções nas sub-redes e no NAT. Eu estou em uma perda. O que estou fazendo errado?

    
por CP510 17.04.2013 / 06:27

2 respostas

4

Para a posteridade, este é um processo de 5 etapas. O host Bastion refere-se ao servidor voltado para o público, que você desejará proteger contra possíveis ataques e através do qual suas conexões viajarão para os servidores da sua sub-rede privada.

Etapa 1: ativar o encaminhamento de IP (host de bastiões)

SSH para o host de bastiões e no prompt, execute o seguinte comando:

echo 1 > /proc/sys/net/ipv4/ip_forward

Etapa 2: Modificar tabelas IP (host bastião)

SSH para o host de bastiões e no prompt, execute os seguintes comandos:

sudo iptables -t nat -A PREROUTING -p tcp -m tcp --dport {PUBLIC_SSH_PORT} -j DNAT --to-destination {PRIVATE_IP_ADDRESS}:22
sudo iptables -t nat -A POSTROUTING -p tcp -m tcp --dport {PUBLIC_SSH_PORT} -j MASQUERADE

onde:

  1. {PUBLIC_SSH_PORT} é a porta no host de bastiões que você planeja conectar por meio de
  2. {PRIVATE_IP_ADDRESS} é o endereço do servidor na sub-rede privada que você planeja conectar a

Para informações mais detalhadas sobre o significado dessas configurações, você pode executar os seguintes comandos no prompt de comando para visualizar as páginas man:

man iptables
man iptables-extensions

Etapa 3: configurar grupos de segurança (console Amazon AWS)

Faça login no seu console Amazon AWS e navegue até o painel Grupos de segurança. Edite o grupo de segurança atribuído ao seu host bastião e adicione:

  1. Regra TCP personalizada para permitir ligações de entrada e saída em {PUBLIC_SSH_PORT} a partir de qualquer endereço IP ao qual irá ligar
  2. Regra TCP personalizada para permitir conexões de entrada e saída para Todo o tráfego de / para o grupo de segurança do servidor privado (digite o ID do grupo de segurança no campo IP personalizado) - você pode restringir isso apenas ao tráfego SSH, mas se você tiver outros serviços e servidores em execução que precisa acessar, essa é a configuração mais simples

Edite o grupo de segurança atribuído ao seu servidor privado e adicione:

  1. Regra TCP personalizada para permitir conexões de entrada e saída para Todo o tráfego de / para o grupo de segurança do host de bastiões (digite o ID do grupo de segurança no campo IP personalizado) - você pode restringir isso apenas ao tráfego SSH, mas se você tiver outros serviços e servidores em execução que precisa acessar, essa é a configuração mais simples

Etapa 4: desativar a verificação de origem / destino (Amazon AWS Console)

Faça login no seu console Amazon AWS e navegue até o painel de instâncias. Clique no host bastião que você acabou de configurar para encaminhar conexões. Desativar verificações de origem / destino no menu de ação. Este é o único dispositivo para o qual as verificações de origem / destino precisam ser desativadas.

Etapa 5: Torne as configurações persistentes (em todas as reinicializações do servidor)

Modifique o arquivo /etc/sysctl.conf e atualize a seguinte linha (alteração de 0 a 1):

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

Salve a configuração iptables (para /etc/sysconfig/iptables ) para que ela seja recarregada na inicialização:

sudo service iptables save

E, finalmente, certifique-se de que iptables seja iniciado durante a inicialização:

sudo chkconfig iptables on

OBSERVAÇÃO : você não precisa configurar e configurar uma instância separada do Amazon NAT para obter acesso SSH a servidores privados. A instância NAT é ideal se você planeja gerenciar o acesso à Internet para vários dispositivos que você pode ter em sua sub-rede privada.

    
por 19.08.2014 / 23:34
2

Você desabilitou as verificações de origem / destino?

Por padrão, a AWS verificará a origem e o destino do tráfego de rede, portanto, uma instância deve ser o destino final de qualquer tráfego enviado ou recebido. Para rotear o tráfego de uma instância para outra, você precisará desativar essa verificação:

link

Outro problema em potencial é que o roteamento não foi ativado no nível do kernel executando algo como:

echo 1 > /proc/sys/net/ipv4/ip_forward
    
por 11.08.2013 / 22:36