Вопрос или проблема
Как определить, зависят ли проблемы с подключением моего сервера от конфигурации сервера или от проблем с маршрутизатором/брандмауэром в сети?
Моя проблема в том, что я не очень хорошо разбираюсь в сетях, а наш IT-специалист не очень разбирается в Linux…
IT-специалист настроил для моего сервера следующие сети:
Production network1: 147.100.157.194/29
- network gw: .193
- server ip: .194
Production network2: 147.100.157.226/29
- network gw: .225
- nas1: .226
- nas2: .227
Management network: 147.100.157.202/29
- network gw: .201
- server ip: .202
- nas1 ip: .203
- nas2 ip: .204
DNS1: 147.100.157.242
DNS2: 147.100.166.31
Идея заключается в том, что сеть MGM доступна только через VPN, но позволяет SSH, в то время как сети PROD доступны только по HTTPS и NFS, но могут быть доступны из более широкой сети.
Я настроил сервер Ubuntu 22.04 с использованием следующего файла /etc/netplan/99_config.yaml
(адаптированного из документации NetPlan):
network:
version: 2
renderer: networkd
ethernets:
enp1s0:
# PROD card/IP (https only)
addresses:
- 147.100.157.194/29
dhcp4: no
routes:
- to: default
via: 147.100.157.193
- to: 147.100.157.192/29
via: 147.100.157.193
table: 101
- to: 147.100.157.226/29
via: 147.100.157.225
table: 101
routing-policy:
- from: 147.100.157.192/29
table: 101
- from: 147.100.157.226/29
table: 101
nameservers:
search: [inra.local]
addresses: [147.100.157.242, 147.100.166.31]
enp69s0:
# MGM card/ip (SSH from VPN only)
addresses:
- 147.100.157.202/29
dhcp4: no
routes:
- to: 147.100.157.202/29
via: 147.100.157.201
table: 102
routing-policy:
- from: 147.100.157.202/29
table: 102
Если я запускаю ip a
, я вижу:
# ip a
1: lo: <LOOPBACK,PROMISC,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: enp69s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:17:b6:00:b3:5c brd ff:ff:ff:ff:ff:ff
inet 147.100.157.202/29 brd 147.100.157.207 scope global enp69s0
valid_lft forever preferred_lft forever
inet6 fe80::217:b6ff:fe00:b35c/64 scope link
valid_lft forever preferred_lft forever
3: enp1s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 04:7b:cb:a9:2a:2e brd ff:ff:ff:ff:ff:ff
inet 147.100.157.194/29 brd 147.100.157.199 scope global enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::67b:cbff:fea9:2a2e/64 scope link
valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:88:7d:2f:d7 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
В данный момент у меня следующие проблемы:
(1) Я не могу подключиться к 147.100.157.202 (нет сообщения, затем Connection timed out
)
Тем не менее, мой sshd, похоже, работает нормально на сервере:
# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2025-01-13 13:59:40 CET; 1h 29min ago
Docs: man:sshd(8)
man:sshd_config(5)
Process: 9213 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 9214 (sshd)
Tasks: 1 (limit: 308926)
Memory: 1.7M
CPU: 13ms
CGroup: /system.slice/ssh.service
└─9214 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"
Jan 13 13:59:40 ncy-beta-compserver systemd[1]: Starting OpenBSD Secure Shell server...
Jan 13 13:59:40 ncy-beta-compserver sshd[9214]: Server listening on 147.100.157.202 port 22.
Jan 13 13:59:40 ncy-beta-compserver systemd[1]: Started OpenBSD Secure Shell server.
(B) Я могу подключиться к серверу, используя https на 147.100.157.194, и открыть терминал там, используя Jupyter. Однако, если я пытаюсь подключиться к какому-то сайту, получаю ошибки:
wget --no-check-certificate http://bbc.co.uk
--2025-01-13 15:25:41-- http://bbc.co.uk/
Resolving bbc.co.uk (bbc.co.uk)... 151.101.0.81, 151.101.64.81, 151.101.192.81, ...
Connecting to bbc.co.uk (bbc.co.uk)|151.101.0.81|:80... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Retrying.
# wget --no-check-certificate https://bbc.co.uk
--2025-01-13 15:26:25-- https://bbc.co.uk/
Resolving bbc.co.uk (bbc.co.uk)... 151.101.0.81, 151.101.64.81, 151.101.192.81, ...
Connecting to bbc.co.uk (bbc.co.uk)|151.101.0.81|:443... connected.
Unable to establish SSL connection.
# curl https://bbc.co.uk
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to bbc.co.uk:443
Связана ли проблема с моей конфигурацией сети сервера или это проблемы в самой сети?
Ответ или решение
Когда возникает вопрос о сетевых проблемах на сервере Ubuntu 22.04, подключенном к нескольким сетям, нужно понять, связаны ли эти проблемы с конфигурацией на сервере или с устройствами типа маршрутизаторов и межсетевых экранов, находящимися между сервером и внешней сетью.
Теория
Проблемы с сетью могут возникать из-за множества факторов. Они могут быть вызваны неправильной конфигурацией сетевого интерфейса на сервере, некорректными маршрутами, неправильно настроенными правилами межсетевого экрана или DNS, а также сложностями соединения на уровне сетевого оборудования (например, маршрутизаторов, свитчей). В ситуации, описанной вами, необходимо последовательно проверить каждый из этих аспектов, чтобы точно определить источник ваших проблем.
Пример
Вы указали несколько сетевых интерфейсов и маршрутизационных таблиц в конфигурационном файле netplan, в том числе две производственных сети и одну управленческую сеть, каждая с собственными шлюзами и IP-адресами. Проблема заключается в том, что вы не можете подключиться к вашему серверу по SSH из управленческой сети, и соединение с некоторыми внешними серверными ресурсами, как bbc.co.uk, сбрасывается.
Применение
-
Проверка конфигурации маршрутизации:
- Убедитесь, что ваши маршруты настроены правильно. Например, в конфигурации netplan, проверьте, что маршруты в таблице 102 правильно настроены для всех IP-адресов в управленческой сети.
- Убедитесь, что маршрутизация настроена таким образом, чтобы пакеты могли попасть в интернет из обеих производственных сетей и вернуться обратно.
-
Проверка правил межсетевого экрана:
- Проверьте правила iptables или другого используемого вами межсетевого экрана. Возможно, что-то блокирует входящие или исходящие соединения, которые необходимы для доступа по SSH или для веб-запросов.
- Важно убедиться, что на устройстве разрешены входящие и исходящие соединения через определенные порты (например порт 22 для SSH).
-
Проверка работы DNS:
- Вы указали несколько серверов DNS в вашем файле netplan. Убедитесь, что они доступны и правильно функционируют. Попробуйте использовать команды, такие как
nslookup
илиdig
, чтобы протестировать их функциональность.
- Вы указали несколько серверов DNS в вашем файле netplan. Убедитесь, что они доступны и правильно функционируют. Попробуйте использовать команды, такие как
-
Диагностика оборудования:
- Попросите вашего IT-специалиста проверить конфигурацию маршрутизаторов или свитчей, если у вас есть доступ к их интерфейсу, чтобы убедиться, что они правильно маршрутизируют пакеты между сетями.
-
Логи и дополнительные тесты:
- Проверьте логи SSH и системные логи через
journalctl
, чтобы найти любые возможные ошибки или предупреждения. - Используйте
ping
иtraceroute
для проверки доступности других узлов сети.
- Проверьте логи SSH и системные логи через
Эти шаги помогут вам установить, является ли источником проблемы конфигурация вашего сервера или сети в целом. Если проблема находится вне зоны вашей ответственности (на уровне маршрутизаторов или межсетевых экранов), потребуется участие вашего системного администратора.