Как выполняется маршрутизация в очень простой настройке OpenVPN?
Я полностью настроил (удаленно) выделенный сервер 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) и я хочу знать, что нужно сделать, чтобы убедиться, что мои интерфейсы не будут "конфликтовать" с другими выделенными серверами.
Я не понимаю, как выполнить настройку, и я не понимаю, как должен выглядеть маршрут.
Чтобы помочь мне понять "общую картину", кто-то может привести точный пример:
- локальный IP-адрес клиента OpenVPN
- IP шлюза, который должен использовать этот клиент OpenVPN
- вывод маршрута сервера OpenVPN
По сути, я немного растерялся, и перед началом я хотел бы понять, как осуществляется маршрутизация на сервере OpenVPN.
Насколько я понимаю, клиенты OpenVPN должны быть в той же сети, что и сервер OpenVPN (используя, скажем, сеть 10.0.0.0/8), но я сталкиваюсь с умственным препятствием, пытаясь выяснить, как клиенты собираются используйте интерфейс 'tun', чтобы затем использовать шлюз 94.xx.yy.254.
1 ответ
Предположим, что 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, все равно будет проходить через шлюз по умолчанию в локальной сети, 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 будет проходить через шлюз локальной сети 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 отключается. Не беспокойся об этой записи.