Настройки сетевого адаптера
Доброго времени суток.
Шлюз локальной сети имеет службу DHCP. После настройки адаптера на статику IPv4 всё равно используется dhcp.
В конфиге \etc\network\interfaces прописал следующее:
auto eth0
iface eth0 inet static
address 192.168.111.104
gateway 192.168.111.254
netmask 255.255.255.0
network 192.168.111.0
broadcast 192.168.111.255
При запуске команды ifconfig я не наблюдаю этих настроек (см. скриншоты). Что странно 104 IP пингуется.
Montfer
New member
Должны были запуститься ваши настройки после перезапуска службы сети (как называется, не помню) либо перезагрузке компа
Volkoff28ru
New member
Благодарю. Прошу прощения за банальную тему. Просто рестарт сети и перезагрузка помогли не с первого раза.
Volkoff28ru
New member
Изменил настройки адаптера утилитой NetworkManager в консольном режиме.
Теперь возникла проблема отсутствия сети. 104 ip не пингуется с других машин и наоборот.
Если я не ошибаюсь, NM не использует конфиг /etc/network/interfaces. Поэтому я его не редактировал.
Соединение не устанавливается при входе в систему, приходиться поднимать интерфейс из терминала. Подскажите какие конфиги посмотреть.
Mrshll
New member
nmcli c s "Проводное соединение 1" .
Чтобы автоматически соединялось посмотрите на параметр connection.autoconnect
Если ни кто не видит — межсетевой экран, vlan. У вас статистика по пакетам нулевая
Volkoff28ru
New member
connection.id: Проводное соединение 1
connection.uuid: 98529d43-354c-356a-b103-1c2f68dbf5d1
connection.stable-id: —
connection.type: 802-3-ethernet
connection.interface-name: —
connection.autoconnect: да
connection.autoconnect-priority: -999
connection.autoconnect-retries: -1 (default)
connection.auth-retries: -1
connection.timestamp: 1552258184
connection.read-only: нет
connection.permissions: —
connection.zone: —
connection.master: —
connection.slave-type: —
connection.autoconnect-slaves: -1 (default)
connection.secondaries: —
connection.gateway-ping-timeout: 0
connection.metered: неизвестно
connection.lldp: default
802-3-ethernet.port: —
802-3-ethernet.speed: 0
802-3-ethernet.duplex: —
802-3-ethernet.auto-negotiate: нет
802-3-ethernet.mac-address: 00:24:1D:61:AF:56
802-3-ethernet.cloned-mac-address: —
802-3-ethernet.generate-mac-address-mask:—
802-3-ethernet.mac-address-blacklist: —
802-3-ethernet.mtu: автоматически
802-3-ethernet.s390-subchannels: —
802-3-ethernet.s390-nettype: —
802-3-ethernet.s390-options: —
802-3-ethernet.wake-on-lan: default
802-3-ethernet.wake-on-lan-password: —
ipv4.method: manual
ipv4.dns: 192.168.111.254
ipv4.dns-search: —
ipv4.dns-options: «»
ipv4.dns-priority: 0
ipv4.addresses: 192.168.111.104/24
ipv4.gateway: 192.168.111.254
Как решить проблему «Временный сбой в разрешении имен»
Иногда, когда вы пытаетесь пропинговать веб-сайт, обновить систему или выполнить любую задачу, требующую активного подключения к Интернету, вы можете получить сообщение об ошибке «временная ошибка в разрешении имени» на вашем терминале.
Например, когда вы пытаетесь пропинговать веб-сайт, вы можете столкнуться с показанной ошибкой:
:~$ ping google.com ping: linux-console.net: Temporary failure in name resolution
Обычно это ошибка разрешения имен, которая показывает, что ваш DNS-сервер не может преобразовать доменные имена в соответствующие IP-адреса. Это может представлять собой серьезную проблему, поскольку вы не сможете обновлять, модернизировать или даже устанавливать какие-либо программные пакеты в своей системе Linux.
В этой статье мы рассмотрим некоторые причины ошибки «временный сбой в разрешении имен» и пути решения этой проблемы.
1. Отсутствует или неправильно настроен файл resolv.conf
Файл /etc/resolv.conf — это файл конфигурации преобразователя в системах Linux. Он содержит записи DNS, которые помогают вашей системе Linux преобразовывать доменные имена в IP-адреса.
Если этот файл отсутствует или есть, но ошибка разрешения имени по-прежнему возникает, создайте его и добавьте общедоступный DNS-сервер Google, как показано ниже.
Сохраните изменения и перезапустите службу systemd-resolved, как показано ниже.
$ sudo systemctl restart systemd-resolved.service
Также разумно проверить состояние распознавателя и убедиться, что он активен и работает должным образом:
$ sudo systemctl status systemd-resolved.service
Затем попробуйте пропинговать любой веб-сайт, и проблема должна быть решена.
2. Ограничения брандмауэра
Если первое решение вам не помогло, возможно, ограничения брандмауэра мешают успешно выполнять DNS-запросы. Проверьте брандмауэр и убедитесь, что порт 53 (используется для DNS — разрешение доменных имен) и порт 43 (используется для поиска whois). Если порты заблокированы, откройте их следующим образом:
Для брандмауэра UFW (Ubuntu/Debian и Mint)
Чтобы открыть порты 53 и 43 в брандмауэре UFW, выполните следующие команды:
$ sudo ufw allow 53/tcp $ sudo ufw allow 43/tcp $ sudo ufw reload
Для firewalld (RHEL/CentOS/Fedora)
Для систем на базе Redhat, таких как CentOS, вызовите следующие команды:
$ sudo firewall-cmd --add-port=53/tcp --permanent $ sudo firewall-cmd --add-port=43/tcp --permanent $ sudo firewall-cmd --reload
Мы надеемся, что теперь у вас есть представление об ошибке «временный сбой в разрешении имен» и о том, как ее исправить, выполнив несколько простых шагов. Как всегда, ваши отзывы очень ценятся.