Вопрос или проблема
У меня есть несколько серверов за маршрутизатором, который требует VPN для подключения к ним, и это работало в течение нескольких месяцев. На этой неделе один из них начал отклонять SSH соединения с VPN, но другие компьютеры в LAN могут к нему подключаться.
Диагностика
- Когда я пытаюсь подключиться по SSH, я вижу пакеты в tcpdump маршрутизатора, но не на сервере.
- Используя интерфейс pfSense, маршрутизатор может пинговать его с интерфейса LAN и клиентов OpenVPN, но не с интерфейса сервера OpenVPN. Другие машины, которые работают нормально, отвечают на пинги от сервера OpenVPN.
- Я добавил правило разрешения NAT из OpenVPN на IP-адрес и порт проблемного компьютера.
Дополнительная информация
Маршрутизатор использует pfSense CE и OpenVPN. Сервер работает под управлением Ubuntu 24.04.
Машина, которая вызывает у нас проблемы, — это единственная, которая использует нестандартный SSH порт, но так было и раньше. Я добавил следующие строки в /etc/ssh/sshd_config
Port 22
Port 51345 # Старый порт
После этого я выполнил systemctl daemon-reload и systemctl restart ssh, но порт 22 по-прежнему закрыт, даже для машин в LAN, и как сообщается nmap.
sshd -T не сообщает об ошибках.
ufw отключен на проблемном хосте.
Никто не признался, что менял что-либо в конфигурации перед тем, как это сломалось.
В LAN нет дополнительной сегментации.
Ответ или решение
Проблема с недоступностью сервера через VPN
Когда вы сталкиваетесь с ситуацией, подобной описанной, важно понимать, что проблема может возникать из различных источников. Давайте рассмотрим ваши выводы и возможные пути для решения проблемы более подробно.
1. Понимание конфигурации и маршрутного регулирования
Основной задачей является то, что один сервер стал недоступен через OpenVPN, хотя его доступность с локальной сети (LAN) сохраняется. На основании предоставленных вами диагностических данных, видно, что пакеты достигают маршрутизатора, но не доходят до самого сервера. Этот факт говорит о том, что проблема, вероятно, связана с маршрутизацией или конфигурацией сетевых правил.
2. Данные о маршрутизации и NAT
Вы упомянули о том, что добавили правило NAT для разрешения соединений от OpenVPN к IP-адресу проблемного сервера. Убедитесь, что правило правильно настроено и соответствует необходимому протоколу и порту (51345). Кроме того, проверьте, охватывает ли правило NAT все необходимые IP-адреса OpenVPN-клиентов.
- Проверка правил Firewall: Убедитесь, что на маршрутизаторе pfSense правила Firewall не блокируют трафик к этому серверу. Это можно сделать через интерфейс pfSense, в разделе "Firewall Rules", где необходимо убедиться, что правила для OpenVPN включают разрешение на проход с OpenVPN интерфейса к внутреннему IP сервера.
3. Проблемы с SSH
Вы указали, что сервер использует нестандартный порт для SSH (51345). На первый взгляд, можно предположить, что сервер вообще не принимает соединения на этом порту. Так как команды sshd -T не указывают на наличие ошибок, проблема может заключаться в том, что служба SSH не запущена на порту 51345.
Шаги для диагностики:
-
Проверка конфигурации SSH: Убедитесь, что конфигурация в файле
/etc/ssh/sshd_configкорректна. Чтобы исключить возможность несовместимости, вы можете временно отключить порт 22, чтобы стартовать только с 51345. -
Проверка запущенных служб: Команда
netstat -tuln | grep 51345покажет, прослушивает ли сервер этот порт. Если нет, возможно, служба SSH не запущена или возникла проблема с конфигурацией. -
Логи SSH: Проверьте системные логи, например командой
journalctl -xeилиtail -f /var/log/auth.log, на наличие ошибок или сообщений о проблемах с SSL-соединениями.
4. Устранение неполадок с pfsense
Поскольку вы можете пинговать сервер из интерфейса LAN маршрутизатора, но не из интерфейса OpenVPN, это может указывать на проблемы с маршрутизацией пакетов обратно к OpenVPN-клиентам.
-
Дополнительные правила NAT: Убедитесь, что правила NAT и маршрутизации включают возврат пакетов с сервера обратно к OpenVPN.
-
Тестирование через telnet: Для дополнительных тестов соединения можете использовать
telnet <IP-адрес_сервера> 51345с клиентских машин для проверки работы порта напрямую.
Заключение
Приняв во внимание все упомянутые аспекты, вы сможете более четко определить источник проблемы и устранить ее. Начните с проверки конфигурации SSH и правил NAT, далее проанализируйте логи и убедитесь, что все сетевые настройки согласованы. Если после всех шагов проблема останется, возможно, стоит рассмотреть перезагрузку сетевых служб или маршрутизатора для устранения временных неполадок.