Установка статического IP-адреса не подключается?

Я следую инструкциям по установке статического IP-адреса для моего удаленного сервера резервного копирования. ( https://www.techrepublic.com/article/how-to-configure-a-static-ip-address-in-ubuntu-server-18-04/)

Я следовал этому набору инструкций:

network:
        renderer: networkd
        ethernets:
            enp0s25:
                dhcp4: no
                addresses: [192.168.111.27/24]
                gateway4: 192.168.1.1
                nameservers:
                         addresses: [192.168.1.1,8.8.8.8]
        version: 2

Но теперь я не могу подключиться к своему серверу, и мне придется восстановить его сетевой план из старой копии, которую я сделал до внесения изменений.

Пользовательский SSH Config:

Host Scilab
  HostName 192.168.43.245
  Port 45834
  IdentityFile ~/.ssh/LesserArkKey

Когда я пытаюсь использовать ssh Scilab Я получил: ssh: connect to host 192.168.43.245 port 45834: Connection refused, Это необычно, потому что раньше это работало (у меня есть пользовательский конфиг ssh). Я изменил текущую конфигурацию ssh на новый IP-адрес (это было 192.168.1.144 ранее)

Что я делаю не так и как я могу установить статический IP-адрес вместо DCHP?

РЕДАКТИРОВАТЬ 0: Для пояснения, вход в систему на основе ключа сервера работает просто отлично, когда на сервере установлен Netplan по умолчанию. ssh Scilab просит ключ шифрования и я даю пароль, и все подключается. Выдает ошибку только при попытке использовать новый Netplan. Тогда ничего не работает.

Все эти команды также терпят неудачу:

sarah@LesserArk:~$ ssh -p 45834 -i .ssh/LesserArkKey 192.168.111.27
ssh: connect to host 192.168.111.27 port 45834: Connection refused
sarah@LesserArk:~$ ssh -p 24 -i .ssh/LesserArkKey 192.168.111.27
ssh: connect to host 192.168.111.27 port 24: Connection refused
sarah@LesserArk:~$ ssh -i .ssh/LesserArkKey 192.168.111.27
ssh: connect to host 192.168.111.27 port 22: Connection refused

Сервер после смены нетплана: ifconfig:

Конфигурация SSHD:

#   $OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 45834
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
MaxStartups 2
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem   sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server

Protocol 2

РЕДАКТИРОВАТЬ 1: Вот выходные данные команд: cat /etc/hosts:

127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

cat /etc/nsswitch.conf | grep "hosts:": hosts: files dns

`networkctl status`:

●        State: routable
       Address: 192.168.111.27 on enp0s25
                fe80::225:64ff:feaf:9fc8 on enp0s25
           DNS: 192.168.1.1
                8.8.8.8

ls -l /etc/resolv.conf: lrwxrwxrwx 1 root root 39 Feb 14 09:49 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

РЕДАКТИРОВАТЬ 2: / etc / hosts:

127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6
192.168.111.27  scilab_comp_0

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Выход из hostname: scilab_comp_0

РЕДАКТИРОВАТЬ 3: Я сделал небольшое видео со своего компьютера (не сервера), показывая более подробную информацию о том, что происходит: https://www.youtube.com/watch?v=rqQGas4fs_A&feature=youtu.be

Сделал быстрое видео о конфликте IP-адресов здесь: https://youtu.be/P2rXWvdOM7k

РЕДАКТИРОВАТЬ 4: Выход telnet 192.168.111.27 45834

sarah@scilab_comp_0:~$ telnet 192.168.111.27 45834
Trying 192.168.111.27...
Connected to 192.168.111.27.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
Connection closed by foreign host.

Сделал еще несколько копаний и заметил, что у меня есть 2 IP адреса для сервера. Вот ip a:

2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:25:64:af:9f:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.27/24 brd 192.168.111.255 scope global enp0s25
       valid_lft forever preferred_lft forever
    inet 192.168.1.142/24 brd 192.168.1.255 scope global dynamic enp0s25
       valid_lft 78971sec preferred_lft 78971sec
    inet6 fe80::225:64ff:feaf:9fc8/64 scope link 
       valid_lft forever preferred_lft forever

Как видите, один динамический, а другой статический. Я не уверен, работает ли статический или нет, хотя или как избавиться от динамического (поскольку я вернул yaml к исходной конфигурации, чтобы я мог получить к нему удаленный доступ в настоящее время со своего компьютера). Учитывая, что в нашем конфигурационном файле указано, что нам нужен только DCHP, откуда поступает статический IP-адрес?

Кроме того, я убедился, что только 50-cloud-init.yaml оказывает какое-либо влияние на конфигурацию. Я добавил префикс.DISABLED в другой файл yaml, который мы создали, поскольку он, похоже, не оказывает никакого влияния.

РЕДАКТИРОВАТЬ 4: Лучшее Тестирование

Я сделал лучший способ проверить, может ли сервер подключиться. У меня есть два окна терминала, вошедших в систему на сервере, и одно просто запускает цикл с while true; do ip a; ping -c3 google.com; date; sleep 10; done, Другой делает sudo netplan try с netplan, чтобы установить статический IP-адрес.

Вот результаты: -Каждый раз, когда IP-адрес становится статическим (После того, как я нажал Enter на другом терминале для `sudo netplan try``, ping завершается ошибкой:

1: lo: <LOOPBACK,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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:25:64:af:9f:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.27/24 brd 192.168.111.255 scope global enp0s25
       valid_lft forever preferred_lft forever
    inet6 fe80::225:64ff:feaf:9fc8/64 scope link 
       valid_lft forever preferred_lft forever
ping: google.com: Temporary failure in name resolution

И каждый раз, когда он возвращается к использованию IP-адреса DCHP (заданного ранее, когда у него было 2 IP-адреса), он возвращается и сообщает информацию в оболочку SSH моего компьютера.

1 ответ

Решение

В конфигурации сетевого плана сервера для статического IP-адреса вы запрашиваете IP-адрес в другой подсети, чем подсеть шлюза. Хотя netplan может назначить этот IP вашему устройству, шлюз не сможет с ним связаться.

Чтобы исправить это, запросите IP-адрес в той же подсети, которая назначена через DHCP. Так что, если назначенный DHCP адрес 192.168.1.15, установите ваш netplan файл yaml следующим образом:

network:
    renderer: networkd
    ethernets:
        enp0s25:
            dhcp4: no
            addresses: [192.168.1.111/24]
            gateway4: 192.168.1.1
            nameservers:
                     addresses: [192.168.1.1,8.8.8.8]

Если вы не уверены в IP-адресе шлюза, выполните следующее, пока у вас хорошее соединение через DHCP:

ip route 

Система ответит чем-то вроде

 default via 192.168.1.1 dev netdev01 ....

В этом выводе шлюз идентифицируется через default via поле.

Для простоты и во избежание проблем, возникающих при настройке DNS и локальной SSH, вы можете отправить клиентский запрос SSH с буквальным IP-адресом сервера:

ssh [email protected]

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

Также, для простоты, я бы сгенерировал мои ключи ssh по умолчанию ~/.ssh/id_rsa.pub если нет веской причины поступить иначе. Это делает кодирование запроса более понятным и простым. Я помещаю открытый ключ в именованный файл только тогда, когда хочу сохранить ключ за пределами моего локального дома или, если я по какой-то причине не могу себе представить, хранить разные ключи для разных хостов.

Другие вопросы по тегам