Openvpn client linux routing

Adding route on client using OpenVPN

So this is my setup. Laptop Running Ubuntu OpenVPN version 2.3.2 I connect to a OpenVPN server that connects to an off-site network. I get the OpenVPN client running and I can ping the VPN server. The server doesn’t push any routes so I need to route on the client. Adding the off-site networks to route to the VPNserver so that I can access the off site network. So the problem I have is that my requests don’t jump from 192.168.0.1 network to the off site 172...* one. Can I do anything about that on my client? I don’t have any ownership of the server and routs are not pushed from server now , in the future i don’t know

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.242.2.6 P-t-P:10.242.2.5 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:100 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:12129 (12.1 KB) wlan1 Link encap:Ethernet HWaddr 5c:93:a2:a0:6e:1b inet addr:10.101.7.41 Bcast:10.101.31.255 Mask:255.255.224.0 inet6 addr: fe80::5e93:a2ff:fea0:6e1b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:355109 errors:0 dropped:0 overruns:0 frame:0 TX packets:206832 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:454685028 (454.6 MB) TX bytes:23942624 (23.9 MB) Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.101.0.1 0.0.0.0 UG 0 0 0 wlan1 10.101.0.0 0.0.0.0 255.255.224.0 U 0 0 0 wlan1 10.242.2.1 10.242.2.5 255.255.255.255 UGH 0 0 0 tun0 10.242.2.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.168.0.0 10.242.2.5 255.255.255.0 UG 0 0 0 tun0 192.168.82.0 10.242.2.5 255.255.255.0 UG 0 0 0 tun0 

Источник

Настройка динамической маршрутизации (в частности BGP) поверх туннеля OpenVPN на Linux (и вероятно *BSD)

Если погуглить на тему «openvpn bgp», то можно найти несколько интересных и полезных с практической точки зрения статей (например раз или два). Но начиная решать задачку вынесенную в заголовок, я по многим причинам даже не удосужился погуглить. Идея пришла как-то сама собой в процессе долгой работы с OpenVPN вообще (в рамках вполне типовых задач, с фиксированным набором сетей с обеих сторон), работы с реализацией OpenVPN на системе RouterOS от MikroTik и стыковки между собой систем на Linux и RouterOS. Собственно в процессе осознания причин написания собственной реализации OpenVPN в RouterOS и пришло «озарение» как можно такую задачу решить в рамках вполне себе штатной редакции OpenVPN. Далее была короткая экспериментальная проверка, показавшая полную работоспособность идеи и запуск этого решения в «промышленную» эксплуатацию.

Помятуя, что таковая ситуация вполне типична для разных применений, а решения, описанного ниже, пока представлено не было, я решил поделиться идеей с сообществом.

Суть проблемы («кто виноват?»)

Чем же так существенно различаются штатная версия OpenVPN и та, что реализована в RouterOS? Отличий вероятно несколько, но в данной статье мы рассмотрим только одно: штатный OpenVPN в системах кроме RouterOS (и возможно некоторых других) является комбайном, который содержит в себе и транспортную часть (то есть собственно передачу пакетов, она же forwarding, он же data plane) и маршрутизирующую (то есть обмен информацией о маршрутах, он же routing, он же control plane), а в RouterOS сервис OpenVPN отвечает только за транспортную часть, а маршрутизацией занимается другой процесс системы, что позволяет с одной стороны не дублировать функциональность маршрутизирующей подсистемы (и тем более не держать несколько одинаковых таблиц маршрутов в разных сервисах и постоянно синхронизировать их между собой), а с другой стороны, позволяет поверх такого транспорта прозрачно осуществлять передачу таблиц маршрутов и изменять таблицы маршрутов с обеих сторон на лету.

Кроме того, штатная реализация OpenVPN имеет ещё один недостаток: передача маршрутов происходит только в одну сторону (от сервера к клиенту) и только в момент установления сессии (то есть поднятия туннеля). Никакого штатного способа добавить маршрут во внутреннюю таблицу маршрутов OpenVPN на ходу в процессе работы туннеля нет, так же как и передать маршруты с одной стороны на другую. Более того, невозможно даже получить саму таблицу маршрутов.

Решение проблемы («Что делать»)

Анализируя свои скрипты, автоматизирующие назначение маршрутов разным клиентам, я обратил внимание, что у OpenVPN есть две различных опции, задающих маршруты:

• iroute — задаёт маршруты внутри таблицы маршрутизации процесса OpenVPN.
• route — задаёт маршруты, которые процесс OpenVPN передаёт в системную таблицу маршрутов (то есть добавляет в таблицу маршруты через свой туннельный интерфейс при подключении и удаляет их же при отключении).

Возник очевидный вопрос: а что будет, если с помощью iroute добавить маршрут 0.0.0.0/0 с обеих сторон, а после этого нужные маршруты (в том числе динамически возникающие или пропадающие) добавлять или удалять на самом туннельном интерфейсе средствами например сервиса маршрутизации (routed, zebra/quagga, bird и т. п.)?

Эксперимент показал, что такая схема действительно работает с небольшим ограничением-неудобством: на один серверный туннель можно подключить только одного клиента. В остальном схема оказалась полностью работоспособной.

Схема работает в режим TLS-over-TCP, то есть для настройки предварительно необходимо сгенерировать ключи и сертификаты SSL.

Ниже привожу примерную конфигурацию OpenVPN для серверной и клиентской стороны.

Конфигурация серверной стороны (по одной для каждого клиента).

Файл server_dyn_rt.conf (сторона сервера)

daemon compress ping-timer-rem persist-tun persist-key tls-server proto tcp-server topology net30 mode server script-security 3 keepalive 15 45 tun-mtu 1500 remote-cert-tls client verify-x509-name name auth cipher local lport dev-type tun dev ifconfig  client-connect client_connect.sh push "route-gateway " push "topology net30" push "persist-tun" push "persist-key" . Diffie-Hellman data  . Certificate Authority certificate data . Server certificate data . Server Private Key data 

Файл client_connect.sh (сторона сервера)

#!/bin/sh echo 'ifconfig-push TUNNEL_CLIENT_SIDE_IP TUNNEL_SERVER_SIDE_IP' >> $ echo 'push "iroute 0.0.0.0 0.0.0.0"' >> $ echo 'iroute 0.0.0.0 0.0.0.0' >> $ exit 0 

Файл client_dyn_rt.conf (сторона клиента)

daemon compress tls-client auth cipher client dev-type tun dev script-security 3 remote-cert-tls server verify-x509-name name remote  tcp . Certificate Authority certificate data . Client certificate data . Client Private Key data 

Настройки пакетов и протоколов маршрутизации не привожу как из-за многообразия пакетов, так и из-за многообразия самих настроек (собственно в качестве источника примеров настройки можно использовать вторую из статей, ссылки на которые приведены в начале статьи). Хочу лишь заметить, что вышеприведённая настройка позволяет использовать в частности BGP (который лично мне нравится как своей «управляемостью», так и способностью передавать маршруты различных протоколов в рамках одной сессии). В случае BGP в качестве адреса соседа (neighbor) на стороне «сервера» следует использовать адрес , а на стороне «клиента» соответственно адрес или же «внутренние» адреса соответствующих сторон, но тогда надо добавлять соответствующие маршруты в конфигурацию сервера и/или клиента.

Плюсы и минусы вышеприведённого решения

1. На один сервер должен приходится строго один клиент, поэтому для нескольких клиентов придётся держать активными несколько процессов OpenVPN. Как следствие — некоторый перерасход памяти и всякое такое.
2. Нельзя использовать режим общего ключа (preshared key) в OpenVPN, потому что в этом режиме запрещена динамическая передача параметров от сервера клиенту (push/pull). Из-за этого требуется более сложная конфигурация, включающая генерацию набора ключей и сертификатов, а также скрипт генерации куска конфигурации клиента на стороне сервера (который правда можно заменить каталогом статических файлов, заменив опцию client-connect /path/to/script на опцию client-connect-dir /path/to/config/dir , что повышает уровень безопасности серверной стороны.

1. В отличие от таких протоколов как GRE/IPIP туннели OpenVPN могут иметь MTU равное 1500 байт (потому что процесс OpenVPN скрывает «под капотом» всю фрагментацию/дефрагментацию, отдавая в туннельный интерфейс пакеты полной длины). Это упрощает настройку всяких вторичных туннелей поверх туннеля OpenVPN.
2. Туннель OpenVPN одновременно поддерживает передачу как протокола IPv4, так и IPv6, что позволяет сократить количество туннелей между парами узлов, затраты на их настройку и администрирование, а также передавать маршруты IPv6 в рамках той же сессии BGP, что и маршруты IPv4.
3. Все плюсы протокола OpenVPN, такие как простота настройки промежуточного сетевого оборудования (или вообще полное отсутствие необходимости в таковой), возможность маскировки трафика под HTTPS, наличие реализации под большинство платформ et cetera, et cetera.

Надеюсь кому-то вышеприведённое руководство окажется полезным.

Источник

Setting up routing

If you set up a routed VPN, i.e., one where local and remote subnets differ, you need to set up routing between the subnets so that packets will transit the VPN.

Here is a possible road warrior network configuration:

Road Warrior (Windows)

TAP-Windows Adapter 10.3.0.2 subnet 255.255.255.0

ifconfig option in OpenVPN config:

ifconfig 10.3.0.2 255.255.255.0

Main Office, server (any OS)

tap adapter 10.3.0.1 subnet 255.255.255.0

ifconfig option in OpenVPN config:

ifconfig 10.3.0.1 255.255.255.0

private ethernet 10.0.0.1 subnet 255.255.255.0

The road warrior needs this route in order to reach machines on the main office subnet:

route add 10.0.0.0 mask 255.255.255.0 10.3.0.1 (this is a shell command)

Routes can be conveniently specified in the OpenVPN config file itself using the —route option:

route 10.0.0.0 255.255.255.0 10.3.0.1

If the OpenVPN server in the main office is also the gateway for machines on the remote subnet, no special route is required on the main office side.

On the other hand, if the main office OpenVPN server is NOT also the gateway, then whatever machine or router, which IS the gateway, must know to route 10.3.0.0 subnet 255.255.255.0 to the machine which is running OpenVPN.

Updates & Announcements

Cyber Shield Released

Cyber Shield protects you from cyber threats without requiring you to tunnel internet traffic. Turn Shield ON.

Release Notes 2.12.0

Access Server 2.12.0 comes with support for Data Channel Offload, a kernel accelerated method of encrypting/decrypting VPN traffic. It also allows setting unique global group subnets so routing in clustering mode is possible. Aside from this numerous fixes and improvements are included.

Access Server

Our popular self-hosted solution. Comes with two free connections. No credit card required.

CloudConnexa™

Cloud-delivered, as-a-service solution. Comes with three free connections. No credit card required.

OpenVPN is a leading global private networking and cybersecurity company that allows organizations to truly safeguard their assets in a dynamic, cost effective, and scalable way.

© Copyright 2023 OpenVPN | OpenVPN is a registered trademark of OpenVPN, Inc. |
CloudConnexa is a trademark of OpenVPN, Inc.

Источник