Создание сервера за VPN-клиентом остается доступным
У меня есть сервер, используемый в качестве веб-и SSH-сервера под Linux. Там работает VPN-клиент с OpenVPN. Если я правильно понял, VPN изменяет таблицы маршрутизации, что приводит к пересылке всего трафика через VPN.
Затем, когда я пытаюсь запросить мой веб-сайт, размещенный на сервере, он становится недоступным. У меня есть базовые знания в области сетевых технологий, но я могу предположить (не стесняйтесь поправлять меня, если я ошибаюсь), что запрос правильно получен сервером через обычный интерфейс, назовем его eth0, но учитывая, что маршрут изменился и теперь проходит через VPN, ответ должен быть отправлен через интерфейс VPN, что, очевидно, невозможно из соображений безопасности.
Я посмотрел следующие темы:
Ответ на тот же интерфейс, что и входящий с IP-адрес DNAT
https://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-incoming
но, к сожалению, они были бесполезны.
Давайте назовем интерфейс VPN tun0, Что я хотел бы сделать, это ответить на запросы на eth0 на том же интерфейсе, а именно eth0 сам, а не tun0 как работает VPN. С другой стороны, мой сервер находится за шлюзом, который отличается от него (два разных IP-адреса).
1) Возможно ли это сделать?
2) Каковы разные способы сделать это?
Заранее благодарю за отзыв.
1 ответ
Наконец, для моей проблемы я нашел решение, основанное на:
https://lartc.org/howto/lartc.rpdb.multiple-links.html.
Вот как это сделать.
Чтобы настроить маршрутизацию сервера таким образом, чтобы она достигалась за VPN-клиентом, следует использовать отдельную таблицу маршрутизации, чтобы избежать наложения конфигураций маршрутизации двух интерфейсов.
Позволять <interface>, <table>, <ip>, <gateway> а также <network> имя интерфейса, таблица, IP-адрес <interface>IP-адрес шлюза и IP-адрес сети (предоставленный провайдером) соответственно.
Процедура, которой нужно следовать:
Создание конкретной таблицы маршрутизации
<interface>: создание новой таблицы<table>в/etc/iproute2/rt_tables,Установка другой конфигурации маршрутизации для интерфейса, связанного с
<gateway>с помощью конкретной таблицы.Движение в сторону
<network>связан с интерфейсом<interface>и следует конкретной таблице маршрутизации<table>:ip route add <network> dev <interface> src <ip> table <table>Построение маршрута по умолчанию через этот шлюз:
ip route add default via <gateway> table <table>На
<interface>, заставляя трафик от<ip>проходя через<network>, чтобы использовать интерфейс<interface>:ip route add <network> dev <interface> src <ip>srcАргумент указан, чтобы убедиться, что выбран правильный исходящий IP-адрес.Связывание интерфейса с соответствующим
<network>:ip rule add from <ip> table
Ключевая идея:
Ключевая идея для понимания того, почему использовать эту технику здесь, заключается в том, что для любого запроса, проходящего через узел ISP, здесь <network>последний будет промежуточным узлом маршрута ответа. Это кажется очевидным, но забывая об этом, вы не понимаете, почему <network> имеет значение в конфигурации маршрутизации интерфейса, обычно используемого для связи с сервером извне.
Необязательно:
Настройка маршрутов для всех пунктов назначения для прохождения
<gateway>а не через шлюз VPN. Полезно, когда необходимо использовать VPN только в каждом конкретном случае.Позволять
<vpn>, а также<vpn's gateway>быть именем интерфейса VPN (обычноtun0) и IP-адрес шлюза VPN соответственно. Тогда маршруты для любых пунктов назначения проходят через VPN, точнее его шлюз<vpn's gateway>, должны быть заменены маршрутами, проходящими через<gateway>:
ip route del 0.0.0.0/1 via <vpn's gateway> dev <vpn>
ip route add 0.0.0.0/1 via <gateway> dev <interface>
ip route del 128.0.0.0/1 via <vpn's gateway> dev <vpn>
ip route add 128.0.0.0/1 via <gateway> dev <interface>
0.0.0.0/1 обозначает IP-адреса в диапазоне от 0.0.0.1 в 127.255.255.255, а также 128.0.0.0/1 из 128.0.0.1 в 255.255.254,
Вуаля.