Вопрос или проблема
Я пытаюсь сделать так, чтобы IPv4-адреса OVH работали на Hetzner. Таким образом, я получаю защиту OVH и не должен получать IPv4-адреса от Hetzner.
IPv4-адреса GRE-туннеля, которые я получил от Noez.de, работают безупречно на Hetzner, и я могу распределять их идеально между своими виртуальными серверами.
Однако при распределении серверов и IPv4-адресов, которые я получил от OVH, я не испытываю проблем локально, но сталкиваюсь с проблемами в публичной сети.
Прежде всего, пожалуйста, не ссылайтесь на следующие темы, так как я уже исследовал и попробовал их:
https://wiki.buyvm.net/doku.php/gre_tunnel
https://lowendtalk.com/discussion/156850/howto-tunnel-ddos-protected-ovh-ip-to-vms-in-other-datacenter/p1
https://lowendtalk.com/discussion/185975/ip-tunneling-from-ovh-to-hetzner
Noez.de напрямую направляет IPv4-адреса на мой конечный сервер, и с помощью следующих команд я могу принимать их и маршрутизировать на сетевой интерфейс, который я создал, без каких-либо проблем. Таким образом, любой, у кого есть этот сетевой интерфейс, может использовать IPv4-адреса (без необходимости в специальном IPv4-адресе).
переменные:
noez_ipv4 = “22.22.22.22”
special_nonexistent_gateway_address = “222.222.222.1”
created_interface = “ens224”
команды:
ip rule add from noez_ipv4 table 20 prio 1
ip addr add special_nonexistent_gateway_address/24 dev created_interface
ip route add default src special_nonexistent_gateway_address dev gre1 table 20
С помощью этих команд мой маршрутизирующий сервер готов. Когда я выбираю этот сетевой адаптер ens224 для своих виртуальных серверов, они могут начать использовать IPv4-адрес 22.22.22.22.
Я не знаю, как Noez этого добился, и хотел бы узнать. Есть ли кто-то, кто может мне помочь с этим?
BuyVM делает это через NAT, но серверы GRE-туннеля могут напрямую подключаться друг к другу.
Например, пусть сервер конечной точки BUYVM: 1.1.1.1, а сервер конечной точки, использующий IP: 2.2.2.2.
Когда мы используем метод NAT BuyVM, при подключении к 1.1.1.1 мы на самом деле подключаемся к 2.2.2.2, но это происходит напрямую между двумя серверами. Я этого не хочу. Похоже, Noez справился с этим, и мне интересно, как они это сделали. Потому что, когда я подключаюсь к серверу конечной точки Noez, мой конечный сервер недоступен. Тем не менее, я могу использовать IPv4-адреса Noez без каких-либо проблем.
Ответ или решение
Решение проблемы GRE-туннеля между OVH и Hetzner
При настройке GRE-туннеля между OVH и Hetzner для использования IPv4-адресов OVH важно учитывать несколько ключевых моментов. Ваши попытки относительно использования адресов Noez.de успешны, но возникает несколько проблем, когда дело доходит до использования адресов OVH на публичной сети. Давайте проанализируем вашу ситуацию и разберемся, что может пойти не так.
Описание проблемы
Вы установили GRE-туннель и успешно получили IPv4-адреса от Noez.de, которые работают без проблем. Однако аналогичные адреса от OVH вызывают трудности в публичной сети, даже несмотря на то, что локально все работает корректно. Это может быть связано с особенностями маршрутизации или конфигурации самих адресов OVH.
Анализ текущей конфигурации
Вы указали, что используете следующие параметры и команды:
noez_ipv4 = "22.22.22.22"
special_nonexistent_gateway_address = "222.222.222.1"
created_interface = "ens224"
Команды, которые вы применяете:
ip rule add from <noez_ipv4> table 20 prio 1
ip addr add <special_nonexistent_gateway_address>/24 dev <created_interface>
ip route add default src <special_nonexistent_gateway_address> dev gre1 table 20
Эти команды позволяют вашему маршрутизирующему серверу правильно обрабатывать и маршрутизировать трафик, однако, когда дело доходит до адресов OVH, ситуация отличается.
Потенциальные проблемы
-
Маска подсети и маршрутизация: Убедитесь, что маска подсети для адресов OVH правильно настроена. Пожалуйста, проверьте, что адреса, которые вы пытаетесь использовать, находятся в диапазоне, который правильно маршрутизируется в Hetzner.
-
ARP-проблемы: Возможно, ваши виртуальные серверы не могут разрешать адреса OVH через ARP. Попробуйте вручную настроить ARP-записи на ваших серверах или убедитесь, что трафик не блокирует межсетевой экран.
-
Проблемы с фаерволлом: Проверьте, не блокирует ли Hetzner или OVH пакеты, соответствующие вашему трафику. Например, ICMP, UDP и другие необходимые протоколы могут быть ограничены.
-
Параметры MTU: Неправильные значения MTU могут влиять на работоспособность туннеля. Убедитесь, что MTU настроен одинаково на обоих концах GRE-туннеля.
Как Noez.de достигает успеха
Согласно вашему описанию, Noez.de обеспечивает прямую маршрутизацию без применения NAT, что дает возможность использовать их адреса с минимальными задержками. Чтобы понять, как это функционирует, важно обратить внимание на:
-
Конфигурация маршрутов: Необходима корректная настройка маршрутизации на стороне Noez, чтобы маршруты к вашим IP-адресам действительно перенаправлялись через их сетевую инфраструктуру к вашему серверу.
-
Протоколы VPN (если применимо): Хотя вы используете GRE-туннель, стоит рассмотреть использование дополнительных протоколов VPN, таких как WireGuard или IPsec, если это поможет в вашей текущей конфигурации.
Рекомендуемые действия
-
Проверьте маршруты и ARP: Проверьте, существуют ли маршруты для IPv4-адресов OVH и правильно ли они прописаны на ваших серверах Hetzner.
-
Отслеживание пакетов: Используйте инструменты, такие как
tcpdump
, для диагностики трафика и определения, попадают ли пакеты на сервер. -
Обсуждение с технической поддержкой: Свяжитесь с поддержкой OVH и Hetzner для прояснения любых специфических требований к маршрутизации или конфигурации.
-
Документация и форумы: Продолжайте исследовать ресурсы, такие как форумы LowEndTalk или другие сети сообщества по хостингу, поскольку они могут предложить ценные советы.
В заключение, работа с GRE-туннелями и маршрутизацией может быть сложной задачей, и требует внимательного подхода к каждому аспекту конфигурации. Ваше желание изучить, как работает Noez.de, вполне разумно и обязательно приведет к распутыванию ряда сложностей.