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

Невозможно открыть порт 21 ftp на centos с помощью firewalld

Я пытаюсь установить vsftpd на Centos 7. Я могу подключиться к серверу с локального хоста, но не могу подключиться к нему с удаленных машин. Я новичок в теме системного и сетевого администрирования.

Вот несколько мест, где я искал ответы:
Не удается открыть порт ftp через firewalld
Centos не открывает порт (а) после добавления правила (ов)
Порт 80 отфильтрован Nmap

У меня работает служба vsftpd:

> netstat -plnt | grep ':21. '
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      12393/vsftpd

и я могу войти, используя ftp localhost просто хорошо. Но когда я пытаюсь выполнить удаленный вход, через несколько секунд я получаю сообщение «Время ожидания соединения истекло». Итак, я подозреваю проблему с брандмауэром.

(Также из FTP-порт закрыт для службы vsftpd

lsof -i:21
COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
vsftpd  12393 root    3u  IPv4 63746670      0t0  TCP *:ftp (LISTEN)

)

Поскольку это Centos, я использую firewalld. Порт 21 появляется быть открытым:

> firewall-cmd --list-services
dhcpv6-client ftp https ssh

и:

> firewall-cmd --list-ports
433/tcp 21/tcp 80/tcp 20/tcp

Также:

> firewall-cmd --get-default-zone
public
> firewall-cmd --get-active-zone
public 
  interfaces: enp0s25

и я перезагрузил firewalld через firewall-cmd --reload

Но если я попробую Nmap с удаленной машины, он утверждает, что порты 20 и 21 отфильтрованы:

> nmap -p20,21 my.ftp.server.com
Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-27 13:48 PDT
Nmap scan report for rrcs-xx-xx-xx-xx 
(xx.xx.xx.xx)
Host is up (0.035s latency).
PORT   STATE    SERVICE
20/tcp filtered ftp-data
21/tcp filtered ftp

Я даже отслеживал, просматривал все правила iptables, следуя различным цепочкам firewalld, и нашел их:

> iptables -S IN_public_allow
-N IN_public_allow
-A IN_public_allow -p tcp -m tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 20 -m conntrack --ctstate NEW -j ACCEPT

Я счастлив опубликовать весь вывод iptables -S если кто-то думает, что это поможет.

Наконец, я отключил SELinux на достаточно долгое время, чтобы определить, что я получаю такое же поведение при его выключении, как и при его включении.

Итак, мои вопросы:

Может ли какая-то другая машина фильтровать трафик порта 21, прежде чем он попадет на мою машину? (На этой машине также есть веб-сервер, к которому я могу нормально подключиться). Если да, то как я могу это определить?

Есть ли еще что-нибудь, что я могу проверить, чтобы отладить эту проблему?

Любая помощь приветствуется.

"Фильтрация" nmap сама по себе не означает, что ваш доступ к FTP заблокирован - это может просто означать, что промежуточный брандмауэр обнаружил, что вы выполняете сканирование и зондирование nmap, и сбросил пакеты. Это довольно распространенная «особенность». К сожалению, после того, как брандмауэр начнет отбрасывать ваши ftp-пакеты, вам придется немного подождать, пока состояние не очистится, чтобы вы могли законно попробовать войти в систему.

Помимо firewalld и iptables, существуют другие службы управления пользователями / портами, которые могут создавать помехи. Один из них - /etc/hosts.allow или /etc/hosts.deny, который предоставляется через tcp_wrappers.

Попробуйте добавить в файл hosts.allow строку, которая гласит:

ALL : YOUR_IP_ADDRESS_HERE : allow

Здесь написано «все порты»: IP: разрешить доступ.

Еще один вопрос, который следует задать, - можете ли вы войти в систему с сервера через его внешний интерфейс вместо псевдонима loopback localhost. ftp MY_IP . localhost часто разрешается входить в систему, даже когда "прослушивание" выключено, например /etc/vsftpd.conf

LISTEN=NO # это в вашем файле vsftpd.conf?

Это потому, что на самом деле он не «слушает» внешний интерфейс ipv4 или ipv6.

Также проверьте свой /etc/services закомментированы ли следующие строки?

services:ftp-data        20/tcp
services:ftp-data        20/udp

Что касается iptables, если вас беспокоит, что правила мешают, просто удалите их:

iptables -F

Итак, я думаю, что порядок операций / проверок таков:

  1. Попробуйте подключиться по ftp к внешнему IP с сервера
  2. Если не удалось подключиться, отметьте netstat -al, и проверьте ваш /etc/vsftp.conf, / etc / services, /etc/hosts.allow - попробуйте еще раз.

Если хорошо, тогда промежуточная фильтрация или фильтрация пакетов на основе источника - ваш враг. 3. В случае неудачи очистите iptables, попробуйте еще раз. 4. Если все еще не удалось, значит, существует другая проблема, мешающая вам войти в систему через локальный сервер.

Если в пункте 2 вы смогли войти в систему, вы все равно захотите попробовать очистить iptables и проверить системный журнал на наличие сообщений об ошибках. Обычно он говорит, что «соединение прервано из источника ...» для входящих соединений, которые не работают с tcp_wrappers.

Также ищите эти строки в vsftpd.conf

pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES

Если вы не можете сузить соединение на своем сервере, пора начать просматривать маршрут к серверу. traceroute MY_SERVER_IP от вашего хозяина, или traceroute MY_CLIENT_IP с сервера. Эта команда также может быть tracepath. Скажу что вполне вряд ли что межсерверный брандмауэр на хостинге блокирует ваши соединения. Если это корпоративная среда, это вполне возможно, даже вероятно, но если среда, в которой находится ваш сервер, является либо хостингом, либо образовательным учреждением, блокировка портов FTP на маршрутизаторе встречается гораздо реже. Это также необычно для клиентских интернет-провайдеров, таких как Comcast.

Как далеко находятся удаленные машины? например сколько сетевых переходов? Если вы находитесь в одной подсети с сервером, то, очевидно, это конфигурация сервера.