Назад | Перейти на главную страницу

После изменения переадресации портов на экземпляре EC2 я больше не могу его просматривать

В настоящее время я не могу просматривать веб-сайт, размещенный на моем экземпляре EC2 (я получаю сообщение об ошибке «Не удалось подключиться»).

Я пытался настроить Node.js на своем экземпляре EC2, и в рамках этого процесса я выполнил следующую команду:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 3000

Node.js работал нормально, но я хотел удалить новое правило, созданное мной выше. В конце концов я понял, что выполнение следующего правила удалит правило:

iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to 3000

Однако после этого я все еще не могу просматривать сайт.

Я столкнулся с этим ответом на аналогичную проблему и выполнил указанные шаги: https://serverfault.com/a/387774.

Брандмауэр

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Проблема с сервером

    root       630     1  0 19:29 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   665   630  0 19:29 ?        00:00:01 /usr/sbin/apache2 -k start
    www-data   666   630  0 19:29 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   667   630  0 19:29 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   668   630  0 19:29 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   671   630  0 19:29 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   878   630  0 19:44 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   879   630  0 19:44 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   880   630  0 19:44 ?        00:00:00 /usr/sbin/apache2 -k start
    ubuntu     896   760  0 20:15 pts/0    00:00:00 grep --color=auto apache
    (No info could be read for "-p": geteuid()=1000 but you should be root.)
    tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      - 

И lsof -Pnl +M -i4 не дает мне никаких записей. Итак, я не уверен, правильно ли это настроено. Apache не слушает другие порты.

Кто-нибудь знает, в чем может быть проблема?

P.S. Перед удалением правила iptables я выполнил iptables -F. Я не уверен, что это могло вызвать проблему.

P.P.S Я подключался к своему экземпляру через SSH с ssh -i mywebsite.pem ubuntu@<ip address of my instance>однако, когда я это делаю, всегда истекает время ожидания. Мое обходное решение заключалось в замене IP-адреса общедоступным DNS моего экземпляра, что позволило мне подключиться. Я не уверен, связано это или нет.

Обновить:

С участием iptables -L -t nat Я получил:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination 
 

Оказалось, что мой эластичный IP каким-то образом отделился от моего экземпляра. Повторное связывание решило проблему.

Судя по вашему сообщению и последующим действиям в комментариях, похоже, вы все сделали правильно. По моему опыту, это означает, что мне не хватает чего-то маленького и фундаментального. Исходя из этого, я вижу две вещи, которые могут доставить вам неприятности:

  1. iptables - я обнаружил, что групп безопасности AWS достаточно для нужд брандмауэра, поэтому, по крайней мере, в качестве эксперимента вы можете отключить iptables, чтобы увидеть, дает ли это вам доступ к вашему веб-серверу. Вы можете запустить их снова сразу после эксперимента, если они являются важной частью вашего профиля безопасности.
  2. IP-адрес - вы упомянули об изменении своего ssh подключение с IP-адреса экземпляра к общедоступному DNS, что говорит мне, что вы используете эластичный IP-адрес, но вы не указали явно, какой IP-адрес вы пытаетесь использовать для веб-соединения. Я всегда обнаруживал, что как только я связываю эластичный IP-адрес с экземпляром, я больше не могу получить доступ к этому экземпляру каким-либо образом через внутренний IP-адрес. В данном случае это означает, что несколько уровней должны быть согласованы: правила DNS и безопасности, разрешающие трафик TCP / 80 на сервер, правила брандмауэра, настроенные для разрешения трафика на этот адрес, веб-сервер, настроенный для ответа на этот адрес (или 0.0.0.0).