Я полностью настроил (удаленно) выделенный сервер Debian GNU / Linux, размещенный на профессиональном уровне, и у меня есть вопрос о сетевой маршрутизации (который AFAICT точно соответствует часто задаваемым вопросам о сбоях сервера).
Этот выделенный сервер имеет статический IPv4 IP и очень простой маршрут:
route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
94.xx.yy.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 94.xx.yy.254 0.0.0.0 UG 0 0 0 eth0
У меня только один статический IP-адрес, и в той же подсети есть много других выделенных серверов, с которыми я не могу связываться.
На этом сервере размещается / обслуживается основное веб-приложение нашей компании (Apache + Tomcat), а также работает Squid. Я сам все настраивал. Как только бюджет позволит, я переведу Squid на другой сервер.
На данный момент я хотел бы добавить OpenVPN на этот сервер (желательно с помощью tun, а не tap), и я хочу знать, что нужно сделать, чтобы быть уверенным, что мои интерфейсы не будут «конфликтовать» с другими выделенными серверами.
Я не понимаю, как должна быть сделана настройка, и я не понимаю, как должен выглядеть маршрут.
Чтобы помочь мне понять «общую картину», мог бы кто-нибудь привести точный пример:
В основном я немного растерялся и прежде чем начать, хотел бы понять, как выполняется маршрутизация на сервере OpenVPN.
Насколько я понимаю, клиенты OpenVPN должны находиться в той же сети, что и сервер OpenVPN (используя, скажем, сеть 10.0.0.0/8), но я наталкиваюсь на мысленный барьер, пытаясь выяснить, как клиенты собираются используйте интерфейс tun, чтобы затем использовать шлюз 94.xx.yy.254.
Предположим, что у VPN-клиента есть следующие настройки IP:
IP eth0: 192.168.1.100
Default gateway: 192.168.1.1
Итак, весь нелокальный трафик будет уходить через 192.168.1.1. Если есть трафик на другой хост в локальной сети, он просто перейдет на этот хост.
OpenVPN запускается, клиент получает новый интерфейс tun0, а затем мы видим что-то вроде:
IP eth0: 192.168.1.100
IP tun0: 10.8.0.13
Default gateway: 192.168.1.1
VPN routing: 10.8.0.1 for the network 10.8.0.0/24
Это предполагает, что сервер OpenVPN не отправляет никаких дополнительных маршрутов. Таким образом, сетевой пакет, идущий, скажем, к 8.8.8.8, по-прежнему будет проходить через шлюз LAN по умолчанию, 192.168.1.1. Пакет, идущий, скажем, на 10.8.0.204, будет проходить через туннель OpenVPN на сервер OpenVPN на 10.8.0.1 для дальнейшей маршрутизации.
Если сервер OpenVPN проталкивает маршрут для своей локальной сети, скажем, 172.16.0.0/24, то приведенная выше маршрутизация VPN может выглядеть так:
VPN routing: 10.8.0.1 for the network 10.8.0.0/24
10.8.0.1 for the network 172.16.0.0/24
Точно так же пакет для 172.16.0.24 пойдет в 10.8.0.1 для дальнейшей маршрутизации.
Если сервер OpenVPN также нажимает настройку "redirect-gateway def1", то шлюз по умолчанию для VPN-клиентов другой. Вы увидите что-то вроде:
IP eth0: 192.168.1.100
IP tun0: 10.8.0.13
Default gateway: 10.8.0.1
(other gateway with lower priority): 192.168.1.1
Static route: 94.xx.yy.zz uses 192.168.1.1
Где 94.xx.yy.zz - это публичный IP-адрес вашего сервера OpenVPN.
В этом случае трафик напрямую для вашего сервера OpenVPN будет проходить через шлюз LAN по умолчанию 192.168.1.1. Трафик, локальный для 192.168.1.0/24, будет просто идти на хосты, как и ожидалось. Любой другой трафик будет использовать 10.8.0.1; нелокальный трафик, который не направляется напрямую к общедоступному IP-адресу сервера OpenVPN, будет проходить через VPN-туннель и выходить из 94.xx.yy.254.
Вы можете увидеть другой маршрут по умолчанию в таблице маршрутизации, который сохраняет 192.168.1.1 в качестве шлюза, но он будет иметь меньший приоритет, чем 10.8.0.1. Я думаю, что это скорее заполнитель для клиента OpenVPN, чтобы он знал, на что установить маршрут по умолчанию после выключения VPN. Не беспокойтесь об этой записи.