Я полностью настроил (удалённо) выделенный сервер Debian GNU/Linux, размещенный в профессиональном месте, и у меня возник вопрос по сетевой маршрутизации (который, насколько я знаю, точно соответствует FAQ по serverfault).
Этот выделенный сервер имеет статический 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 отключится. Не беспокойтесь об этой записи.