Основная система линукс, на ней стоит машина на винде, машина на винде айпишник получает натом, то есть у хоста айпишник условно 172.16.15.52, а машина получает айпишник 192.168.1.55 В настройках маршрутизации на координаторе прописано, что если от пула айпишников 172.16.15.0-256 идёт запрос на айпишник 98.37.240.203 (рандомно написал, просто белый айпишник любого сайта), то оно должно ходить по прямому маршруту в интернет через условный порт eth0, но если запрос идёт от других айпишников, то запрос должен идти на мой координатор, там обрабатываться и ходить по юзергейту на левый айпишник э Так вот вопрос в чем, когда юзер ходит через линукс, то координатор отрабатывает всё как да, ходим через белый айпишник в обход координатора, но если юзер ходит с винды, то я вижу, что оно чуть подлагивает и ходит через юзергейт (при шифровании расшифровании появляется время дополнительное) Трассировка с линукса показывает, что юзер сначала прыгает на шлюз 172.16.15.254 (да, мой шлюз координатора) и всё проходит норм, трассировка с винды показывает, что юзер сначала прыгает на шлюз 192.168.1.254, а потом уже на мой шлюз 172.16.15.254 (мой координатор), может ли координатор думать, что к нему приходят запросы с 192.168.1.52 или он думает, что если оно сначала прыгнуло на 192.168, а потом на 172.16, значит запрос поступил с айпишник 172.16.15? И что в этом случае делать? Macvtap же мне поможет? Я читал что маквтап даёт один айпишник на машину и хост, просто разные порты Под окном 100 машин, все так ходят, то есть проблема не в конкретном
Eternusta, интересный кейс! Похоже, что проблема связана с тем, как настроена маршрутизация в вашей сети и как работает NAT (Network Address Translation) для виртуальной машины на Windows. Когда трафик идёт с машины на Windows, он сначала попадает на шлюз виртуальной сети (192.168.1.254), который перенаправляет его на основной шлюз (172.16.15.254). Это может вызывать дополнительные задержки, так как трафик проходит через дополнительный уровень NAT перед тем, как достигнет координатора. Что касается использования macvtap, это может быть хорошим решением. Macvtap позволяет виртуальной машине появляться в физической сети с собственным MAC-адресом, что может помочь избежать двойного NAT. Виртуальная машина будет вести себя как обычное устройство в сети, получая IP из того же диапазона, что и хост-машина, и используя те же маршруты. В вашем случае, если вы настроите macvtap для виртуальной машины Windows, она должна начать получать IP из пула 172.16.15.0/24 и напрямую использовать шлюз 172.16.15.254 без дополнительного перехода через виртуальный шлюз 192.168.1.254. Это должно уменьшить задержки и упростить маршрутизацию. Однако, стоит учитывать, что macvtap имеет свои ограничения, например, виртуальная машина не сможет общаться с хост-машины через сетевой интерфейс macvtap. Если это критично для вашей сетевой архитектуры, возможно, потребуются дополнительные настройки или использование других методов виртуализации сети.
ChatGPT в продолжение нашего разговора выше про хост и виртуальные машины: а как при macvtap машина будет получать айпишник? Один айпишник с хостом или разные? Если один, то просто порты разные, я же правильно понял? Если разные, то у меня выделенный пул в 200 адресов быстро же закончится (мне как бы пофиг, но просто) И не совсем понял к чему ты написал про то, что машина не сможет общаться с хостом, если я правильно понял, то просто у машины будет свой порт и зачем ей вообще с хостом общаться, если у нее шлюз теперь будет один с хостом Ап по кнопке
Eternusta, давай разберёмся с macvtap и как это работает в контексте получения IP-адресов и взаимодействия с хостом. Macvtap — это способ сетевого моста, который позволяет виртуальной машине (VM) использовать один и тот же физический интерфейс, что и хост, но с разными MAC-адресами. Это позволяет каждой VM иметь свой собственный IP-адрес, отличный от IP-адреса хоста, даже если они используют один и тот же физический интерфейс. Таким образом, IP-адреса не делятся между хостом и VM; они полностью независимы. Что касается вопроса о количестве IP-адресов: да, если у тебя много VM, и каждая из них получает свой уникальный IP-адрес из пула, этот пул может быстро исчерпаться. Это важно учитывать при планировании сетевой инфраструктуры. Относительно взаимодействия между хостом и VM при использовании macvtap: основная особенность здесь в том, что трафик между хостом и VM не может проходить напрямую через macvtap интерфейс. Это связано с тем, как работает механизм macvtap — он не передаёт трафик между хостом и VM напрямую. Если тебе нужно, чтобы VM могла общаться с хостом, тебе придётся использовать другие методы, например, настройку дополнительного сетевого интерфейса или использование различных маршрутов и правил в брандмауэре для перенаправления трафика. Надеюсь, это проясняет твои вопросы по macvtap и помогает в планировании твоей сетевой инфраструктуры! Если есть ещё вопросы или нужна дополнительная информация, не стесняйся спрашивать.