Назад | Перейти на главную страницу

Совместное использование диска между сетями с одной и той же подсетью

У меня есть две сети, физически отдельные и разные. У них обоих одинаковая подсеть 192.168.1.0 сетевая маска 255.255.255.0. Мне нужно передать диск в обе сети. Все мои хосты - Linux. установка двух сетевых адаптеров в одну подсеть на одном ПК не работает. Нет, я не могу изменить сетевой IP-адрес одной из сетей, что, конечно, является самым простым решением. Использование двух ПК, на которых один пытается повторно экспортировать общий ресурс NFS с другого, не работает, поскольку NFS не позволяет повторно экспортировать общие ресурсы NFS. Я попытался использовать виртуальную машину (VMWARE), которая решила все проблемы с подключением, за исключением того, что она не может экспортировать через NFS общую папку типа vmhgfs. конечно, это не такая уж уникальная ситуация.

Я не могу редактировать сети, потому что устройства, которые пытаются смонтировать этот общий диск по NFS, являются "черными ящиками" самолета, их встроенный код жестко запрограммирован для монтирования NFS 192.168.1.10:/diskB в одной сети и 192.168.1.11:/diskB в другой сети. В самолете есть две сети для резервирования. В реальном самолете есть блок, который может сделать это и одновременно обслуживать обе сети через эти жестко закодированные IP-адреса. Я пытаюсь смоделировать эту коробку, потому что получение полетной коробки займет больше года (все текущее производство предназначено для реальных самолетов).

Ваша проблема - одна из многих проблем IPv4, которые были решены в IPv6. В этом отношении я рассматриваю вашу проблему как проблему поддержки устаревших устройств, поддерживающих только IPv4, в мире IPv6.

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

Запускайте сервер как IPv6-only, по крайней мере, с точки зрения ядра. Запустите программу в пользовательском режиме, которая передает IPv4 на одном физическом сетевом интерфейсе и преобразует его в IPv6 на виртуальном сетевом интерфейсе, представляя трафик ядру.

Вы можете запустить столько экземпляров этой программы, сколько физических сетевых интерфейсов вам необходимо поддерживать. Каждый экземпляр программы отвечает за отдельный сетевой интерфейс. Каждому экземпляру программы необходимо выделить диапазон IPv6 / 96, что составляет ничтожно малое количество адресов IPv6.

Используя этот подход, я ранее реализовал программу NAT64, которая позволила мне использовать одну машину в качестве клиента в двух отдельных сетях IPv4 с одинаковыми префиксами и одинаковым адресом шлюза.

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

Параметры программы будут следующими:

  • Какой сетевой интерфейс использовать
  • Какой IPv4-адрес у программы на этом интерфейсе
  • Какой префикс IPv6 / 96 у виртуального интерфейса

Программа должна получать запросы ARP для своего IPv4-адреса и отвечать на них. Ему необходимо выполнять запросы ARP для любого клиента, с которым ему нужно общаться и кэшировать ответы. И ему необходимо переводить пакеты между IPv4 и IPv6.

Сопоставление адресов между IPv4 и IPv6 будет следующим:

  • От IPv4 к IPv6 добавьте к адресу настроенное / 96.
  • Из IPv6 в IPv4 сравните первые 96 бит адреса с настроенным префиксом.
    • Если есть совпадение, удалите первые 96 бит, чтобы найти адрес IPv4.
    • Если совпадений нет, создайте ответ без маршрута к хосту.

Правильный ответ -

  • поместите две физически отдельные сети в отдельные IP-сети и используйте маршрутизатор для маршрутизации между ними,
  • или присоединитесь к двум физически разделенным сетям, используя VLANS на коммутаторе уровня 2.

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

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

Обновление: использовать бесклассовое IP-подсети (CIDR), 25 бит. Переместите сеть A в нижнюю часть подсети, а сеть B в верхнюю часть. Возможно, вам придется повторно IP-адрес одной или обеих сетей. Настройте запоминающее устройство в третьей сети (ради Пита используйте другую частную подсеть). Экспортируйте запоминающее устройство в каждую 25-битную сеть CIDR.

Обновление 2: используйте облачное хранилище.

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

Вы можете попробовать настроить подсеть на интерфейсе, который общается с черными ящиками, назначив ему IP-адрес 192.168.1.12, подсеть 255.255.255.248 и широковещательную передачу 192.16.1.15.

Затем установите для другого интерфейса IP-адрес 192.168.1.100 и дайте ему подсеть 255.255.255.248, которая будет иметь широковещательную передачу 192.16.1.103.

Итак, мне удалось заставить работать одну из моих ранних неудач. Я создал виртуальную машину (VMware) на моем хосте RHEL7. Я также установил RHEL7 в качестве гостевой ОС. На хосте у меня IP 192.168.1.10 на одной сетевой карте. другой сетевой адаптер включен, но ему не назначен IP-адрес на ХОСТЕ. вместо этого виртуальная машина имеет подключенную к ней сетевую карту с использованием IP 192.168.1.11. Затем я создал «общую папку» на моем diskB и смонтировал ее как / diskB с типом vmhgfs в моей виртуальной машине. Я включил nfs на хосте и экспортирую / diskB. Вот и вся уловка. в виртуальной машине я не мог использовать ядро ​​nfsd, вместо этого я создаю NFS-демон пользовательского пространства unfsd. Затем я запускаю этот файл с правами root на экспортируемой виртуальной машине / diskB. теперь обе сети счастливы, и клиенты в любой из них могут видеть изменения, сделанные клиентами в другой сети.