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

Rate this post

В процессе донастройки своей виртуальной сети 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

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

Related Posts

Настройка WP Mail SMTP для работы с Yandex 360 (WordPress)

Я уже рассказывал как настроить различные способы отправки электронной почты используя разного рода локальные почтовые сервера или mail-relay, но это скажем так небольшой overhead и если вам надо настроить разного…

Сброс MikroTik до заводских настроек

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

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

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

Возможно вы пропустили

Настройка WP Mail SMTP для работы с Yandex 360 (WordPress)

Настройка WP Mail SMTP для работы с Yandex 360 (WordPress)

Сброс MikroTik до заводских настроек

Сброс MikroTik до заводских настроек

Полезные плагины для VsCode

Полезные плагины для VsCode

Маленькое путешествие в Томск

Маленькое путешествие в Томск

Настройка Proxy/VPN сервера (Часть вторая SOCKS5)

Настройка Proxy/VPN сервера (Часть вторая SOCKS5)

Ого! На этой версии реинкарнации моего блога я написал уже 150 статей.

Ого! На этой версии реинкарнации моего блога я написал уже 150 статей.