Немного заметок по настройке сетей в Linux

Оцените статью

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

Маршрутизация в Linux

Если предполагается, что сервер или рабочая станция будет использоваться как маршрутизатор или шлюз в интернет, то обязательно разрешаем net.ipv4.ip_forward в файле /etc/sysctl.conf.

net.ipv4.ip_forward=1

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

Временно можно включить так.

# echo 1 > /proc/sys/net/ipv4/ip_forward

Или так.

# sysctl -w net.ipv4.ip_forward=1

Проверяем.

# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Не повторяйте моих глупых ошибок.

Настройка Cloud Init в NetPlan

Если в имени настроек Net Plan видим файлы видим файлы вида /etc/netplan/50-cloud-init.yaml, то с высокой степенью вероятности ваша система управляется хостинг провайдером и при перезагрузке изменения будут удалены. Следовательно, для дополнительных настроек создаем отдельный файл, например такой cat ./90-lxd-bridge.yaml. Порядок применения по первым цифрам в имени файла.

network:
  version: 2
  bridges:
    lxd-br:
      dhcp4: no
      addresses:
      - "10.101.5.1/24"

Отключаем NetPlan Cloud-Init для настройки сети

При добавлении интерфейса контейнеру командой.

# lxc config device add test-container eth0 nic nictype=bridged parent=lxd-br name=eth0

Создается файл /etc/netplan/50-cloud-init.yaml.

network:
    version: 2
    ethernets:
        eth0:
            dhcp4: true

Так как это все тот же наш любимый cloud-init и вот теперь для того, чтобы использовать статическую адресацию, его надо отключить. Для этого создаем файл /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg содержащий.

network: {config: disabled}

Так же приведу пример конфигурации для статической адресации с указанием шлюза по умолчанию.

network:
    version: 2
    ethernets:
        eth0:
            dhcp4: false
            addresses:
            - "10.101.5.2/24"
            routes:
            - to: "default"
              via: "10.101.5.1"

Проверяем, что все работает.

# ip a
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
12: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:c5:85:2e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.101.5.2/24 brd 10.101.5.255 scope global eth0
       valid_lft forever preferred_lft forever
# ip route
default via 10.101.5.1 dev eth0 proto static 
10.101.5.0/24 dev eth0 proto kernel scope link src 10.101.5.2 
# ping 10.101.5.1
PING 10.101.5.1 (10.101.5.1) 56(84) bytes of data.
64 bytes from 10.101.5.1: icmp_seq=1 ttl=64 time=0.113 ms
64 bytes from 10.101.5.1: icmp_seq=2 ttl=64 time=0.075 ms

Не забываем про маршруты

При настройке по инструкции «Объединение bare-metal и vps серверов в коммутируемую сеть при помощи OpenVPN» не забываем настраивать на клиентах маршруты до новых подсетей, как например в моем случае с LXD.

Можно записать маршрут в файл инициализации моста.

ip route add 10.101.5.0/24 via 10.100.1.4

Но лучше конечно использовать push-маршруты с сервера OpenVPN.

NetPlan аналоги pre-up, post-up и т.п.

Вот еще одно изобретение нетплановцев. Теперь вы не можете просто описать скрипты исполняемые при поднятии интерфейса, а вам придется пострадать с  networkd-dispatcher. Небольшая, но интересная статья по всяким нововведениям при использовании NetPlan есть тут https://netplan.io/faq/#use-pre-up%2C-post-up%2C-etc.-hook-scripts.

В принципе, тема с network-dispatcher вполне себе рабочая, но в моем случае это небольшой overhead и я просто сделал аналог устаревшего скрипта rc.local по свой инструкции «Поддержка rc.local в современных версиях Ubuntu Linux» и добавил туда правило NAT для того что бы контейнеры LXC могли ходить в интернет.

В итоге, получился вот такой rc.local.

#!/bin/sh

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t raw -F
iptables -t raw -X

iptables -t nat -A POSTROUTING -s 10.101.5.0/24 -o enp0s5 -j MASQUERADE

exit 0

И в целом больше ничего интересного не было.

Похожие записи

Настройка взаимодействия RED ADM и Windows Active Directory

Сегодня проведем несколько экспериментов по настройке взаимодействия RED ADM и Windows Active Directory. Есть несколько способов настройки доверия для упрощения миграции с решений Microsoft на Российское ПО и сегодня их…

Подробная инструкция по написанию YAML‑файлов для Docker Compose

Так как на севере делать абсолютно нечего, то я продолжаю заниматься саморазвитием 🙂 На этой неделе вспоминаю и углубляю свои знания в Docker. Лучший способ запомнить тему, это вести конспект…

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Читать еще статьи

Настройка взаимодействия RED ADM и Windows Active Directory

Настройка взаимодействия RED ADM и Windows Active Directory

Подробная инструкция по написанию YAML‑файлов для Docker Compose

Подробная инструкция по написанию YAML‑файлов для Docker Compose

Установка основного контроллера домена на базе REDADM

Установка основного контроллера домена на базе REDADM

zVirt работа с шаблонами виртуальных машин

zVirt работа с шаблонами виртуальных машин

Подробная инструкция по работе с томами (volumes) в Docker

Подробная инструкция по работе с томами (volumes) в Docker

Сетевые возможности Docker

Сетевые возможности Docker