Сеть в Linux

Основы сети

Представим ситуацию, когда у нас два компьютера подключены к сети через коммутатор и у обоих хостов назначены свои адреса. В таком случае, мы сможем пингануться от одного устройства к другому и проверить их на взаимодействие внутри сети.

Коммутатор (switch) позволяет соединить два хоста в одну сеть.

Далее нам нужно подключить две разных сети, чтобы они могли обмениваться данными. Для этого нам нужен будет маршрутизатор (router). Он занимается объединением нескольких сетей в одну. Представляет он из себя сервер с множеством сетевых портов.

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

Чтобы попасть в эту сеть к маршрутизатору извне используется Шлюз (aka Gateway), который и является дверью во внешний мир.

Команда route представляет нам информацию по сетям, доступную ядру линукса.

Команда ip route add 192.168.2.0/24 via 192.168.1.1 откроет нам доступ к сети 192.168.2.0 через роутер 192.168.1.1

Чтобы настроить возможность отправить пакеты с системы4 на систему2, нам нужно будет так же настроить доступ к маршрутизатору на данных машинах.

(первая команда связывает верхнюю сеть коммутатора с маршрутизатором)

(вторая команда выполняет подключение к гуглу второй сети через маршрутизатор)

(третья команда подставляет дефолтный (default aka 0.0.0.0), т.е. любой ip-адрес назначения, на которой полетит потом запрос, если не будет найден искомый)

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

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

ip link - перечисление изменение интерфейсов на хосте ip addr - просмотр адресов назначенных этим интерфейсом ip addr add - предусмотрен для установки адресов на интерфейс ip route - просмотр таблицы маршрутизации. ip route add - используется для добавления адреса в таблицу маршрутизации

Чтобы сохранить внесённые изменения даже после перезагрузки, нужно установить их в конфиг роутов в /etc/* своего дистрибутива

Трансляция сетевых адресов

NAT - трансляция сетевых адресов

У нас есть сеть с первой и второй системой, которые связаны через свич, выход в интернет через роутер с белым ip (т.е. с ip не из частного диапазона), подключенным к интернету. Роутер подсоединён к коммутатору, чтобы провайдить интернет на наши ПК.

Система1 сейчас пытается отправить пакет со своего ip на rotoro.cloud:80. У него есть поля отправителя и получателя. С компьютера этот пакет переходит на первый и второй порты роутера и затем идёт в интернет до получателя информации.

Но ответ обратно Системе1 не поступит, потому что понять, что за ip такой отправил в интернет пакет - не понятно.

Чтобы понять, кто был отправителем данного файла на сервер, роутер поднменяет отправителя на свой ip, но с указанием порта устройства в данной сети (которое отправило файлы на сервер). Роутер сохраняет новый ip отправителя к себе в таблицу и указывает, кто был отправителем пакета в своей локальной сети. После получения ответа, роутер проверяет по таблице, кто является настоящим получателем ответа от сервера и направляет ответ на Систему1, которая и отправила пакет.

Чтобы реализовать общение двух компьютеров Фиолетового и Жёлтого из разных сетей, мы можем использовать переадресацию через другой Синий.

Если это сделать через ip add, то компьютеры будут общаться по своим настоящим айпишникам.

Чтобы избежать данной проблемы, нам нужно научить отправлять компьютеры запрос, прячась за их NATом.

Но мы можем воспользоваться командой: iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE, которая позволит скрыть отправляемые из первой сети запросы под NAT синей машины

Делается это всё для того, чтобы избежать проблем с поиском адресата на ответное сообщение, когда сеть предприятия очень большая и требует общения большого количества устройств в сети с одинаковыми ip-адресами.

Сети в VM

У одного хоста может быть несколько ip-адресов. Обычно новые ip-адреса он может получить от подключения разных коннекоторов от других устройств, которые вызывают DHCP. К хосту можно обратиться по любому ip-адресу и получить ответ. Если один из коннекторов нашего хоста не подключён к сети, то сообщение потеряется и не дойдёт до нас.

В VirtualBox мы можем настроить до четырёх адаптеров. Наша выходящая сеть из виртуалки по-дефолту настроена как NAT.

Первый вариант сети в VM - Host-only. В таком случае, у нас создаётся локальная сеть внутри нашего хоста, который раздаёт разные ip-адреса своим виртуальным машинам внутри одной подсети, которая не связана с внешним миром - только с нашим хостом.

Чтобы создать такую сеть, нужно перейти в менеджер сетей. Серез Create создать новую сеть с таким типом. Перейти во вкладку Network каждой из виртуальных машин и задать тип сети вместе с именем созданного адаптера.

Второй вариант. Наш хост виртуальных машин должен предоставить всем VM доступ в интернет. В таком случае, мы выбираем NAT Network.

Данный способ будет подставлять в качестве отправителя сообщения ip-адрес нашего хоста и перенаправлять ответ в нужную виртуальную машину

Установка сети ровно такая же, как и в прошлый раз. В менеджере сетей нужно создать новую сеть NAT.

И далее назначить её машине, указав тип сети и имя созданной сети.

Так же у нас есть и третий вариант использования - NAT. Такой способ реализации выхода в сеть опускает создание общей сети между компьютерами и теперь запросы будут напрямую транслироваться в сеть через ip хоста наших виртуальных машин.

Так же у нас есть способ подключения виртуалок напрямую к нужной нам сети через Bridged Network (мостовую сеть). При таком способе все виртуальные машины получат ip-адреса напрямую от той сети, к которой они подключены и будут общаться с ней и образуется связанная внешняя локальная сеть с нашей основной виртуальной сетью.

В разных случаях подключение к интернету реализовано по-разному

1. NAT подключется к интернету через ip хостовой машины.
2. Host-only позволит принимать в себя сеть только при переадресации сети с ip хоста на ip внутренней локальной сети, которая располагается на хосте (aka хост-машина становится маршрутизатором). Либо можно подключить к виртуальной машине второй сетевой интерфейс и подключить его к NAT вместо перенаправления.
3. Bridge подключается напрямую по мосту к нужной виртуальной сети.

Далее нужно определиться с портами. К самим ip-адресам нужно относиться как к коду страны, по которому мы попадаем к нужной нам сети с тысячами абонентов-компьютеров.

В одной сети по одному ip у нас может располагаться и БД и сервер, но выходить они будут в сеть по разным портам.

Ну и так же мы можем реализовать переадресацию портов на нашей хостовой машине к портам на виртуальных

Настраиваются порты в Port Forwarding. Для каждой виртуальной машины нужно использовать разные порты, так как при подъёме двух виртуалок с открытым портом 22 переадресация ssh подключения будет падать

Domain Name System

Имена

Бывают такие случаи, когда обращаться к серверу по ip-адресу достаточно неудобно. Чтобы решить эту проблему, можно записать в /etc/hosts заранее имя определённого ip, как алиас - <ip> <алиас>. В таком случае, при запросе ping db-server мы будем долбиться на имя этого ip.

Система1 считает файл хостов доверенным и не проверяет наименование удалённого компьютера, к которому обращается. Удалённый компьютер может сам по себе называться по-разному.

Мы так же можем обмануть нашу Систему1 и назвать удалённый хост в виде Системы2 яндексом

Разрешение имён

Раньше такими алиасами пользовались, когда в сети было немного устройств. Если разрастить сеть до большого количества устройств, то поддерживать всю эту архитектуру станет крайне сложно.

DNS

Но сейчас используют DNS-сервер, который упрощает обращение между хостами в сети, давая определённым ip-адресам имена.

Чтобы указать адрес dns-сервера, нам достаточно в etc/resolv.conf указать сервер имён.

Однако у нас может произойти так, что записано одно и то же имя локально и на днс-сервере, но скрывают они разные ip-адреса. Тут уже будет превалировать порядок просмотра, который записан в etc/nsswitch.conf, который в поле hosts хранит порядок просмотра. Если в первом источнике есть имя, то линукс будет брать и сопоставлять это имя с ДНСом. Изначально сверка идёт по нашему локальному файлу, а затем только сверка с днс-сервером. Этот порядок можно поменять.

Если мы не можем достучаться до определённого ресурса и с нашим локальным, и с удалённым dns, то мы можем воспользоваться сервером 8.8.8.8, который предоставляет гугл. Этот сервер имён знает о существовании всех сайтов в интернете.

Добавить мы можем её как локально nameserver 8.8.8.8, так и на сам днс-сервер, чтобы он редиректил запрос на поиск всех неизвестных имён на днс гугла.

Доменные имена

Все имена .ru, .net (социальные сети), .com (коммерческие или общие цели), .org (некоммерческие организации) являются доменами верхнего уровня, которые определяют назначение сайта.

Обычная ссылка выглядит следующим образом:

• Корень - из него исходят веб-страницы
• Домен верхнего уровня - определяет назначение сайта
• Доменное имя - определяет имя самого сайта в интернете
• Сабдомен - позволяет группировать домены по их группе, целям и назначению. Все поддомены можно делить на большое количество нужных нам доменов.

Обычно www называют основную страницу сайта. Другие поддомены, например, как drive или mail отвечают за другие инструменты того же домена (инструменты, которые предлагает гугл, как почту, диск и так далее).

Если мы ищем google.com в интернете, то у нас идёт следующий порядок:

• если на нашем хосте нет имени ip-адреса искомого ресурса, то мы идём в dns нашей организации
• если в dns нашей организации нет искомого имени, то мы идём в интернет
• интернет обращается к dns, который отвечает за .com домены, а уже тот отправляет запрос в dns гугла, чтобы получить ответ

После выполнения всех операций, dns организации получает нужный список имён, и, зачастую, кэширует результат у себя, чтобы не проходить весь путь заново.

Если мы локально в нашей организации используем определённые имена в доменах наших сервисов, то есть возможность сократить запись.

Вместо того, чтобы обращаться по длинному имени к app.rotoro.corp, чтобы достучаться до app, мы можем добавить в resolv.conf запись search rotoro.corp, которое скажет нам искать поддомены в определённом домене.

Типы записей в DNS

• A - запись ip-адреса хоста
• AAAA - запись ipv6
• CNAME - сопоставление имён (используется для записи псевдонимов одного и того же приложения)

Инструменты

Команда nslookup позволяет получить информацию об определённом домене. Эта команда не работает с локальным файлом хостов - только с удалённым dns-сервером.

Команда dig возвращает все детали о домене в том же формате, в котором это хранится на сервере.

Команда host выводит информацию подобную дигу с различными опциями.

Инструменты диагностики сети

Интерфейсы

ip:

• link - отобразит исправность работы всех сетевых устройств
• addr / a - отобразит адрес и маску подсети (а так же отобразит все физические и виртуальные интерфейсы)
• route / r - отобразит имеющиеся gateways

Команда ifcondig представляет собой старый вариант ip a

Команда dmesg выведет сообщения всех интерфейсов. Она зачастую нужна, чтобы понять, какой интерфейс является виртуальным, а какой физическим.

Команда route является аналогом ip r.

Проверка сети

Команда ping позволяет проверить пересылку пакетов по сети. С помощью ключа -s можно указать размер пакетов, которые будут пересылаться (зачастую это нужно, чтобы проверить потерю больших пакетов).

arp -vn позволит проверить mac-адреса, которые находятся в одной сети с нашим сервером.

Команда traceroute -I -n ya.ru позволит отобразить путь движения пакетов. Обычно нужно, когда мы находимся не в одной локальной сети. Мы сможем посмотреть, отправляет ли пакет маршрутизатор или все последующие после него промежуточные сети, а так же есть ли ответы от всех данных единиц в сети.

Команда tracepath -n ya.ru делает то же самое, но работает не из под рута.

Если идут потери пакетов, то можно воспользоваться mtr ya.ru, которая отследит все проблемы.

Проверка DNS

Команда nmcli connection show eth0 | grep dns позволит проверить более подробно интернет-соединения. Работает в дистрибутивах с network manager по типу RedHat.

systemd-resolve --status позволяет взглянуть на днс на системах с netplan.

Если с помощью утилит днс разрешает имя верно, а с помощью последних двух команд внутренний днс не разрешает, то с ним есть проблема. Если нигде нет подключения, то нужно взглянуть на 53 порт TCP или UDP (это порты прослушивания dns).

Проверка портов

ss -tulpn позволяет взглянуть на порты netstat -tulpn сделает то же самое, но это более старая и медленная утилита

Опции -tu позволяют вывести протоколы TCP и UDP. -l - те порты, что прослушивает система. -p, чтобы узнать, какая программа слушает порт. -n отобразит числа вместо имён хостов.

Так же можно взглянуть на файлы открытых соединений через lsof -i -P -n.

iptables -L выведет список правил работы портов firewall-cmd --list-all выведет список фаервола

curl <устройство>:<порт> позволит дёрнуть http запрос на получение каких-либо данных Либо можно воспользоваться текстовым терминалом telnet db01 3306, чтобы дёрнуть нужную информацию.

Устранение проблем

1. Проверяем работу интерфейсов через ip link
2. Дальше мы должны проверить возможность получить ip для имени искомого хоста nsllookup <имя_хоста>
3. Далее нужно проверить, возможно ли физически достичь искомого ip-адреса. Первый вариант - ping <ip-адрес>, но он не является самым надёжным спосообом. Второй вариант - traceroute <ip-адрес>, который отобразит, на каком этапе произошла ошибка. В примере у нас ошибка выпадает на третьем участке (оба роутера работают, но запрос не принимает сам сервер).
4. Далее нужно уже проверять сам сервер, так как проблема на нём. Дёрнем ip link на сервере и увидим, что адаптер сети упал. Поднять адаптер можно через ip link set <устройство (dev)> <адаптер (enp1s0f1)> up.
5. Адаптер поднят, но пингануться опять не получается. Сейчас уже стоит проверить порты на сервере через netstat -tlpn | grep 80 | grep -i LIST. Так как ответа нет, то на 80 порт ничего не выходит. Проверим службу nginx через systemctl nginx status, а затем поднимем через start, если она не запущена.