Порты и брандмауэр: что закрыто на арендованном сервере

Взял сервер под ночные прогоны. Всё, что ходит по 443, летает. Всё, что ходит на 1080, висит и отваливается по таймауту. На домашней машине с тем же конфигом работает обе схемы.

Хостер отвечает «ограничений нет». Хочу прийти к нему с фактами на руках. С чего начать разбор?

Начните с того, чтобы отличить два разных отказа. Их путают постоянно, а говорят они о противоположных вещах.

Отказ приходит мгновенно, значит кто-то ответил. Висит до таймаута, значит пакет уехал в тишину и ответа не будет.

У меня ровно тишина, тридцать секунд и таймаут. Дальше как понять, кто её устроил: своя машина, хостер или сеть по пути?

Своя машина проверяется первой, она под рукой.

sudo iptables -L OUTPUT -n -v
sudo nft list ruleset | head -40
sudo ufw status verbose

Если ufw стоит в режиме deny outgoing, дальше можно не искать. Такое приезжает в готовых образах сплошь и рядом, а человек про исходящие правила даже не думает, потому что привык закрывать входящие.

подскажите, а группы безопасности у хостера тоже на исходящие работают? думал они только входящие фильтруют

Работают, Егор, и это второе по частоте место после локальных правил.

Теперь по существу, раз тема пошла вглубь. Мест, где режется исходящее соединение, всего три, и они различаются по поведению.

Локальный брандмауэр отбивает пакет сразу, на выходе из ядра. Внешне похоже на таймаут, но пакет наружу вообще не выходит, и tcpdump на сетевой карте пуст. Это самый быстрый способ отличить: запускаете слушателя, дёргаете соединение, смотрите, вышел ли SYN.

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

Сеть по пути ведёт себя третьим образом. Иногда возвращается ICMP с пометкой запрета, и тогда в выводе появляется административный отказ. Иногда молчит. Здесь помогает traceroute по нужному порту: видно, на каком узле маршрут перестаёт отвечать.

Практический вывод из всего этого: связку, которая обязана жить в любой сети, вешают на 443. Этот порт открыт почти везде, потому что закрыть его означает выключить половину рабочего интернета.

На Windows та же история выглядит иначе, добавлю для полноты. Там исходящие правила привязаны к программе, и запрет прилетает по имени файла, номер порта тут дело второе. Свежесобранный скрипт с новым именем ведёт себя как незнакомец.

netsh advfirewall firewall show rule name=all dir=out | findstr /i progon
netsh advfirewall monitor show firewall

Отдельно посмотрите профиль сети: правила для доменного и для общедоступного профиля разные, и машина после переезда легко оказывается в другом профиле.

Прошёл по порядку. Локальные правила пустые, SYN на карте виден, повторы идут. Полез в кабинет хостера, там на исходящие разрешены три порта из списка, остальное молча гасится. Правил я не создавал, приехало с образом.

Хорошо, что докопались. Мелочь на будущее: после правки правил проверяйте с самого сервера. Панель показывает намерение, машина показывает результат. У меня был случай, когда правило показалось применённым, а на деле висело в очереди минут пять.

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

Заодно перевёл рабочую связку на 443, как советовал tcpdump_fan. Теперь при переезде на любой сервер она поедет без разговоров с поддержкой.

спасибо, забрал себе всю ветку в закладки