Невозможно открыть порт ftp 21 на centos с помощью firewalld
Я пытаюсь установить vsftpd на Centos 7. Я могу подключиться к серверу с localhost, но не могу подключиться к нему с удаленных машин. Я новичок в теме системного и сетевого администрирования.
Вот несколько мест, где я искал ответы:
Невозможно открыть порт ftp через firewalld
Centos не открывает порт / порты после правила / s добавлены
Порт 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 строку, которая гласит:
ВСЕ: ВАШ_IP_ADDRESS_HERE : allow
Здесь написано "все порты" : IP: разрешить доступ.
Другой вопрос, можно ли войти в систему с сервера через его внешний интерфейс вместо псевдонима localhost loopback. ftp MY_IP . localhost часто разрешается входить в систему, даже когда выключен "listen", например, /etc/vsftpd.conf
LISTEN=NO # есть ли это в вашем файле vsftpd.conf?
Это потому, что на самом деле это не "прослушивание" внешнего интерфейса ipv4 или ipv6.
Также проверьте ваш файл /etc/services, закомментированы ли следующие строки внутри или снаружи?
services:ftp-data 20/tcp
services:ftp-data 20/udp
Что касается iptables, если вы беспокоитесь о том, что правила мешают, просто промойте их:
iptables -F
Поэтому я думаю, что порядок операций/проверки следующий:
- Попробуйте подключиться к внешнему IP с сервера
- Если не удается подключиться, проверьте
netstat -al, а также /etc/vsftp. conf, /etc/services, /etc/hosts.allow -- попробуйте еще раз.
Если OK, то промежуточная или исходная фильтрация пакетов - ваш враг. 3. Если не получится, промойте iptables, попробуйте еще раз. 4. Если все еще происходит сбой, есть еще какая-то проблема, препятствующая входу через локальный сервер.
Если в точке 2 вы можете войти, вы все еще хотите попробовать смыть iptables и проверить syslog на наличие сообщений об ошибках. Обычно это говорит о том, что "соединение оборвано с исходным кодом..." для входящих соединений, которые не работают с 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.
Как далеко находятся удаленные машины, например, сколько прыжков в сеть? Если вы находитесь в одной подсети с сервером, то очевидно, что это конфигурация сервера
.