Как настраивают сеть?

Сеть работает по принципап:
- связи на физическом уровне, медный провод, оптоволокно, радио канал;
- связи на логическом уровне, VLAN, ТУННЕЛЬ, ШИФРОВАНИЕ,
- связи на уровне адресного пространства, IP адреса.

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

Так же должна быть связь на логическом уровне, т.е. общее шифрование или общий VLAN, прочее.

Доступность по адресному пространству, т.е. если IP адрес находится в одном адресном пространстве, то в случае если два выше стоящих условия выполняются происходит обмен пакетов.

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

(по всей видимости это происходит при перебоях в электропитании, и отключении/подключении сетевого интерфейса).

Если вы пишете, что вы настраивали и у вас всё работало, но даже при отключении / подключении провода у вас связь терялась, то вывод только один: вы просто выполнили настройку командами, не прописав нужные настройки в конфигурационные файлы настройки сети вашего Linux. А при отключении / подключении провода выполняются сценарии про возникновении событий pre_up / post_up, pre_down / post_down и по этим событиям выполняется перенастройка интерфейсов в соответствии с конфигурационным файлом.

сетевой интерфейс wgN работает в lxc-контейнере. У меня вопрос - нужно ли именно в этом же контейнере иметь обычный интерфейс, который будет обеспечивать прохождение пакетов до удалённого узла с «сервером» wireguard, или пакеты из интерфейса wgN сразу попадают в ядро, а оттуда уходят с хостовой машины? Нужно ли хождение обычных пакетов настраивать в контейнере, или на хосте?

У меня вопрос - нужно ли именно в этом же контейнере иметь обычный интерфейс

Нужно что бы внешний реальный IP адрес сервера был доступн клиентам для подключения, т.к. клиенты подключаются на определённы внешний IP адрес и порт, устанавливают шифрованное соединение и тем самым поднимают шифрованный VPN канал.

В общем, т.к. работает любое клинт-серверное приложение.

Я сейчас мучаюсь с настройкой «клиента». Сервер находится с другой стороны и у него всё прекрасно с доступностью для подключения.

Мне непонятно, как пакеты уходят с клиента, поэтому я задал вопрос про wireguard в этом сообщении.

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

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

В этом пакете заголовок с IP адресом назначения из VPN сети и поле с передаваемыми данными.

----------------------------------------------------------------
|  VPN_IP | VPN DATA                                           |
----------------------------------------------------------------

Далее wireguard сервер, а точнее модуль работающий в простанстве ядра смотри какому абоненту на какой адрес нужно отправить шифрованный пакет.

Определяет его и создаёт ещё один IP пакет, в нём уже заголовок с IP адресом назначения из внешней реальной сети, а не VPN и в поле данных находится весь шифрованный IP пакет из VPN сети.

--------------------------------------------------------------
|         | Encrypted Data                                   |
| real_ip | VPN_IP | VPN DATA                                |
--------------------------------------------------------------

После чего пакет уходит через рельный интерфейс.

После чего пакет уходит через реальный интерфейс.

Какой из двух? Тот, который настроен в хостовой системе, или тот, который настроен в lxc-контейнере?

Какой из двух? Тот, который настроен в хостовой системе, или тот, который настроен в lxc-контейнере?

Тот который настроен в контейнере. Хостовый в контейнере у тебя вероятно не видно вообще.

А можно ли сделать так, чтобы пакеты уходили через хостовый интерфейс, а в контейнере был только один интерфейс wgN, без ethM ?

У тебя в контейнере должно быть два интерфейса. Один «виртуальный», пакеты, которые отправляются через него не уходят в сеть, а перехватываются и шифруются wireguardом. Второй «настоящий», через который wireguard отправляет шифрованые пакеты в сеть.

В начачале через интерфейс контейнера, а потом через интерфейс хост системы, если конечно в контейнер не проброшена сетевая карта как оборуование через passthrough.

Да, сейчас вроде бы так и есть, как ты говоришь. Вывод всяких там утилит есть выше.

Но если бы можно было оставить в контейнере только один интерфейс, это было бы интересно.

Я думаю, что интерфейс в контейнере включен на хосте в один мост с физическим интерфейсом.

Я так думаю потому что brctl show показывает

# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.f617032c339c	no		dummy0
							enp8s0
							guestos

dummy0 тут для того, чтобы мост не разрушался при отключении интерфейса enp8s0 и неактивном контейнере.

То есть, по моему пониманию, настройка сетевого интерфейса enp8s0 на хосте никак не влияет на хождение пакетов из контейнера, правильно?

Но если бы можно было оставить в контейнере только один интерфейс, это было бы интересно.

Нафига?

Можно запустить wireguard на хосте. Будет на хосте два интерфейса, «виртуальный» и «настоящий». Потом в контейнер пробрасываешь только виртуальный.

мне непонятны слова «запустить wireguard» (он ведь модуль ядра, а не демон, запускаемый из systemd в пространстве процессов), а так же «пробрасываешь».

Нафига?

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

br0 - это логическое объединение интерфейсов в один логический физический канал.

А далее связь осуществляется посредством IP адресации и если у вас на enp8s0 назначен IP адрес по которому доступен контейнер из вне, то удалив его или опустив, вы потеряете связь с внешним миром и VPN тоже работать не будет.

Т.к. пакет маршрутизируются между IP адресами.

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

IP адрес назначается на мост в целом. Так что он не может быть разным для enp8s0 и dummy0, я так думаю...

Попробуйте.

Что попробовать? Если я попробую поменять конфигурацию моста, то у меня пропадёт доступ через ssh к этой машине, на которой lxc-контейнер с клиентом wireguard.

Значит делаем вывод, что dummy0 - это какой-то специфический интерфейс, который не имеет связи на физическом уровне к тому физическому каналу, через который есть доступ к интерфейсу хост системы.

Можно запустить wireguard на хосте.

мне непонятны слова «запустить wireguard» (он ведь модуль ядра, а не демон, запускаемый из systemd в пространстве процессов)

Ключевое слово — «хосте». «Твоя ситуация сейчас: ip addr выполненый В КОНТЕЙНЕРЕ показывает интерфейс wr3. Тебе нужно: ip addr выполненый НА ХОСТЕ показывает wrЦифра. Т.Е. настроить wireguard не в контейнере, а в хосте.

а так же «пробрасываешь».

Сделай так, чтобы в br0 не было enp8s0, а был wgЦифра.

ip addr на хосте сделай.

dummy0: <BROADCAST,NOARP,UP,LOWER_UP>

Без ARP работать сеть не будет.

я уже писал выше, что dummy0 это неиспользуемый интерфейс, через него пакеты не ходят и нужен он только для того, чтобы мост br0 не пропадал при отключении/подключении enp8s0

Хорошо, а что физически подключено к enp8s0?

к enp8s0 подключен физический шнур, которой идёт в сторону NAT, оттуда в интернет, оттуда в сторону серверной части этого wireguard-соединения.

Как-то так: настраиваешь wireguard на хосте, получаешь интерфейс wrX. Через brctl создаёшь ещё один мост brX. Убираешь guestos из br0. Добавляешь guestos в brX. Добавляешь wrX в brX. Удаляешь wr3 из контейнера. В контейнере остаётся только eth0, он соеденён с guestos в хосте, guestos соеденён через brX с wrX.

br0 и enp8s0 с настроеным ip-адресом работают по старому, ssh не сломался.

это всё верно, и после такой настройки контейнер будет ходить только через VPN. Но это не отвечает на вопрос «почему пакеты не ходят прямо сейчас». Вдруг я перенастрою wireguard на хосте, а пакеты всё ещё не будут ходить?

Смотрите, br0 - это своего рода просто коммутатор, свич, в который подключено несколько проводов.

У вас сервер с NAT находится в том же сегменте сети, с той же адресацией (192.168.2.0/24), что и br0.

Поэтому вам и нужно, что бы в br0 был интерфейс enp8s0, т.к. только в этом случае пакет смаршрутизируется до шлюза.

Ну дык я тоже не вижу, почему они не ходят.

wireguard-сервер вообще пингуется?

Может пакеты идущие из guestos через br0 попадают не в enp8s0, а в dummy0 и выкидываются нахрен? Попробуй удалить dummy0 из br0.

Если из br0 удалить enp8s0, то т.к. IP адрес из сети 192.168.2.0/24 назначен на мост, то пакеты в enp8s0 не пойдут.

Может пакеты идущие

Чего я вангую, таблицу маршрутизации посмотри.

wireguard-сервер вообще пингуется?

да, он пингуется изнутри контейнера.

пакеты идущие из guestos через br0 попадают не в enp8s0, а в dummy0 и выкидываются нахрен?

Мост отличается от свитча там, что пакеты через него идут во все стороны.

Мост отличается от свитча там, что пакеты через него идут во все стороны.

Нет. Но если вас так заботит bridge, тогда настраивайте openvswitch.

Попробуй удалить dummy0 из br0.

не получается:

# brctl delif br0 dummy0
# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.f617032c339c	no		dummy0
							enp8s0
							guestos

таблицу маршрутизации посмотри.

# ip route show 
default via 192.168.2.1 dev br0 proto static 
192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.2

Вот и ответ, удалять enp8s0 из моста нельзя.

никто и не предлагал. Предлагали удалить dummy0.

А смысл? У него стоит флаг noarp и через него в принципе пакеты не пойдут.

Не понятно вообще, что ты хочешь сделать.

Я хочу выяснить причину, по которой пакеты не идут из lxc-контейнера через wireguard с адреса 10.0.0.3 на адрес 10.0.0.1.

не получается:

Забей, если сервер из контейнера пингуется, значит нормально br0 работает. Он же не может различать wireguard/не wireguard.

iptables нечего не режет?

Ломается не маршрутизация, а сам wireguard? Тупо перезагрузиться пробовал?

Настройки wireguardа?

Смотрите, в контейнере у вас есть:

eth0: 192.168.2.203/24
wg3: 10.0.0.3/8

На хост системе:

br0: 192.168.2.2/24
guestos@if18: нет адреса
enp8s0: нет адреса

В br0 есть интерфейсы dummy0, guestos и enp8s0.

Когда пакет пойдет до VPN сервера он должен иметь доступ до 192.168.2.1, а для этого т.к. на хосте адрес из 192.168.2.0 назначен на br0, а на enp8s0 нет адреса и в контейнере такое же адресное пространство, в котором находится и шлюз 192.168.2.1, то все участники сети должны быть в одном физическом канале.

Т.е. guestos и enp8s0 должны быть либо подключены к одному свичу, либо в нашем случае к одному мосту.

Т.к. когда приходит пакет и ядро принимает решение куда его, а точнее на какой интерфейс его направить оно в начале ище интерфейс с той же сеть, что и IP назначение и что бы пакет дошёл от адреса 192.168.2.203 до 192.168.2.1 в мостдолжны быть объединены enp8s0, через который доступен 192.168.2.1 и guestos, а IP адреса на br0 может не быть.

Но если нужно подключаться по SSH из сети 192.168.2.0 на хост, то в данном случае IP адрес может быть назначен либо на br0, либо на enp8s0.

В такой схеме постероения сети всё будет работать только так.

Т.е. для того, что бы пакет ищ

И, скорее всего, когда откючается провод от enp8s0 он вываливается из моста или не происходит поднятие enp8s0 после переподключения провода.

Тупо перезагрузиться пробовал?

да (только что), ничего не меняется, пакеты ходить не начинают.

iptables нечего не режет?

не режет. Раньше же работало, и я его не перенастраивал.

Настройки wireguardа?

Что конкретно надо проверять? Адрес внешнего сервера прописан правильно, порт тоже. Вообще вряд ли, т.к. в прошлые разы всё решалось шаманством с хождением пакетов.

192.168.2.1 из контейнера сейчас пингуется, а в VPN пакет не ходят?

в мостдолжны быть объединены enp8s0, через который доступен 192.168.2.1 и guestos

так и есть

IP адрес может быть назначен ... на br0

так и есть

когда откючается провод от enp8s0 он вываливается из моста или не происходит поднятие enp8s0 после переподключения провода.

тогда бы не работал ssh, и выше мы видим, что enp8s0 в мосте.

А пакеты по wireguard не ходят.

Я так и не понял, что надо сделать, чтобы начали.

192.168.2.1 из контейнера сейчас пингуется, а в VPN пакет не ходят?

да. И это не «сейчас», а так и было с начала топика.

Что конкретно надо проверять?

Если бы кто знал.

После сбоя питания у тебя не меняется внешний ip-адрес? Сервер тебя не зафильтровал?

10.0.0.1 вообще существует?

Подсеть на сервере точно 10.0.0.0/8?