Проблемы с сетевым подключением на сервере Ubuntu 22.04 под несколькими сетями: проблема конфигурации сети сервера или в самой сети?

Вопрос или проблема

Как определить, зависят ли проблемы с подключением моего сервера от конфигурации сервера или от проблем с маршрутизатором/брандмауэром в сети?
Моя проблема в том, что я не очень хорошо разбираюсь в сетях, а наш 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, сбрасывается.

Применение

  1. Проверка конфигурации маршрутизации:

    • Убедитесь, что ваши маршруты настроены правильно. Например, в конфигурации netplan, проверьте, что маршруты в таблице 102 правильно настроены для всех IP-адресов в управленческой сети.
    • Убедитесь, что маршрутизация настроена таким образом, чтобы пакеты могли попасть в интернет из обеих производственных сетей и вернуться обратно.
  2. Проверка правил межсетевого экрана:

    • Проверьте правила iptables или другого используемого вами межсетевого экрана. Возможно, что-то блокирует входящие или исходящие соединения, которые необходимы для доступа по SSH или для веб-запросов.
    • Важно убедиться, что на устройстве разрешены входящие и исходящие соединения через определенные порты (например порт 22 для SSH).
  3. Проверка работы DNS:

    • Вы указали несколько серверов DNS в вашем файле netplan. Убедитесь, что они доступны и правильно функционируют. Попробуйте использовать команды, такие как nslookup или dig, чтобы протестировать их функциональность.
  4. Диагностика оборудования:

    • Попросите вашего IT-специалиста проверить конфигурацию маршрутизаторов или свитчей, если у вас есть доступ к их интерфейсу, чтобы убедиться, что они правильно маршрутизируют пакеты между сетями.
  5. Логи и дополнительные тесты:

    • Проверьте логи SSH и системные логи через journalctl, чтобы найти любые возможные ошибки или предупреждения.
    • Используйте ping и traceroute для проверки доступности других узлов сети.

Эти шаги помогут вам установить, является ли источником проблемы конфигурация вашего сервера или сети в целом. Если проблема находится вне зоны вашей ответственности (на уровне маршрутизаторов или межсетевых экранов), потребуется участие вашего системного администратора.

Оцените материал
Добавить комментарий

Капча загружается...