Главная » Linux

Linux vpn add route

На чтение 10 мин Просмотров 1 Опубликовано
Содержание
  1. Route everything through VPN except SSH on Port 22
  2. 2 Answers 2
  3. Added bonus
  4. Linux vpn add route
  5. Для начала настроим dnsmasq.
  6. Теперь самое время завести тот самый список VIAVPN
  7. Переходим к маршрутизации
  8. Top 3 способа передачи маршрутов удаленным VPN-клиентам
  9. Adding route on client using OpenVPN

Route everything through VPN except SSH on Port 22

I have a server and I want to setup a VPN on it to route all traffic. Of course I don’t want to block myself out when establishing the OpenVPN connection (already did that!) so I want port 22 to be unaffected and be reachable as usual. Is this possible? And if so, how can I set this up?

Set it all up accordingly (just port 22) but I still cant SSH onto server and have to do a hard reboot. I am using Ubuntu 14.04 . Which OS did you use when u got it working? Also in your answer I think the part of echoing «201 novpn» into etc/iproute2/rt_tables is missing?

2 Answers 2

You need to add routing to your server so ssh packets get routed via the server’s public ip not the vpn. Failing to do that means the ssh return packet gets routed via openvpn. This is why you get locked out of your server after you’ve inititated an openvpn client session.

  • Public IP is a.b.c.d
  • Public IP Subnet is a.b.c.0/24
  • Default Gateway is x.x.x.1
  • eth0 is device to gateway

iproute2 is your friend here. Do the following:

ip rule add table 128 from a.b.c.d ip route add table 128 to a.b.c.0/24 dev eth0 ip route add table 128 default via x.x.x.1

Do route -n to confirm new routing table shows up. Above commands won’t persists if you reboot the server. You’ll need to add them to your network interface config file.

Then run your openvpn client config openvpn —config youropenvpn-configfile.ovpn &

Added bonus

Also, should you wish to restrict traffic to your public IP to ssh and only ssh then you’ll need to add iptables filtering as follows:

iptables -A INPUT -d a.b.c.d -p tcp --dport -j ACCEPT iptables -A INPUT -d a.b.c.d -j DROP

ps: I recall first learning about this in the Linode’s forum — google it and you should be able to find a post on this.

Источник

Linux vpn add route

портфолио

Уровень сложности материала — средний.

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

У нас есть Linux сервер, который, помимо прочего, функционирует в качестве маршрутизатора. Весьма распространенная ситуация, ее и будем рассматривать, как пример. На схеме изображена типичная структура сети основного офиса и филиала:

Читайте также:  Linux комбинации клавиш gnome

Задача настроить Linux роутер таким образом, чтобы обращения к сайту example.org шли через VPN.

  1. Dnsmasq — рекурсивный кэширующий DNS сервер для обслуживания запросов клиентов (сотрудников)
  2. ipset — утилита и поддержка одноименного модуля в ядре
  3. iptables – утилита для конфигурирования netfilter, c поддержкой ipset
  4. iproute2 – пакет для расширенного управления маршрутизацией и QoS

Будем исходить из того, что VPN соединение уже настроено; при подключении создается устройство соответствующего типа (ppp или tun).

Логически решение выглядит так:

  • Сотрудник набирает адрес example.org в браузере
  • Dnsmasq «видит» домен в конфигурационном файле, резолвит, как обычно, + заносит IP адрес(-а) в таблицу ipset с названием VIAVPN
  • Правилом iptables, пакеты с соответствующим «тэгом» ipset — VIAVPN, помечаются меткой 1 (—set-mark 1)
  • В таблице маршрутизации, все пакеты с меткой 1, отправляются через интерфейс VPN

Рассказывать как установить пакеты на вашей версии Linux я не буду, надеюсь вы уже можете это сделать самостоятельно. Тем более дистрибутивы разные, и приводить в качестве примера какой-то конкретный, считаю неправильным.

Для начала настроим dnsmasq.

В первую очередь, нас интересуют вышестоящие (upstream) DNS серверы, к которым будут направляться запросы. Сам по себе, dnsmasq является, своего рода, прокси сервером. По умолчанию данная информация берется из системных настроек, файла resolv.conf. Однако можно указать альтернативный файл с помощью строки (dnsmasq.conf)

resolv-file=/etc/resolv.dnsmasq

Укажем список доменов для занесения соответствующих им IP адресов в ipset list с именем VIAVPN

ipset=/example.org/example2.com/example3.edu/VIAVPN

Через разделитель «/» можно указать любое количество доменов. Обращаю внимание, что все субдомены тоже попадут в ipset. В конце строки указывается название листа, в нашем случае VIAVPN.

Теперь самое время завести тот самый список VIAVPN

# ipset create VIAVPN hash:ip family inet

Указывается тип списка – ip адреса со структурой хранения hash. То есть, с очень быстрым, фактически мгновенным, поиском IP адреса в огромном списке. Именно по этой причине используется ipset, а не напрямую правила iptables. Family inet говорит об адресах протокола IPv4.

Правило iptables, которое будет маркировать пакеты, к IP адресам доменов (то есть с пометкой VIAVPN), маркером 1. По сути, мы меняем одну метку на другую, но беда в том, что селкторы ip rule не могут работать с ipset, лишь с fwmark. Данное правило как раз служит исключительно для этого:

# iptables -I PREROUTING -t mangle -m set —match-set VIAVPN dst -j MARK —set-mark 1

Команда не требует каких-то особых разъяснений, всё достаточно очевидно. Единственное, dst говорит о направлении трафика. То есть, извлекаем из пакета адрес назначения и проверяем его наличие в списке VIAVPN. Если присутствует, помечаем такой пакет меткой 1.

Переходим к маршрутизации

Ну, первое, конечно, заводим отдельную таблицу, назовем ее vpnrouting. Идем в файлик /etc/iproute2/rt_tables и добавляем туда строку

Читайте также:  Бэкап всего сервера linux

ID может быть любым свободным положительным числом до 255

Добавляем маршрут по умолчанию (default gateway) в созданную таблицу. Кроме него, в нашем случае, больше ничего не понадобится, однако, сюда можно добавить другие, более точные маршруты при необходимости

# ip route add table vpnrouting default dev tun0

Поскольку, интерфейс VPN, как правило, point-to-point — можно указать вместо адреса соседнего маршрутизатора, устройство, с которого следует отправлять пакеты. Что мы и сделали.

Почти всё готово! Осталось указать, в какой таблице искать маршруты для пакетов с меткой (fwmark) 1. Если добавлять маршруты через упрощенную утилиту route, то они, на самом деле, прописываются, в таблицу main. А правило для всех пакетов, по умолчанию, ищет маршруты именно в ней.

Выведем список всех правил поиска маршрута для наглядности:

# ip rule show
0: from all lookup local
32766: from all lookup main
32767: from all lookup default

Тут всё просто, число слева — это приоритет. Для поступившего пакета ищется маршрут, начиная с наименьшего, по возрастанию. Сначала, в таблице local, там содержится информация о широковещании и адреса локальных интерфейсов. Таким образом ядро распознает широковещательные пакеты, а так же те, которые адресованы данной машине. Если маршрут для пакета не найден, проверяется следующая таблица – main. В ней всё то, что мы видим по команде «route –n». В том числе маршрут по умолчанию.

Задача указать правило поиска ДО таблицы main. По умолчанию, оно будет добавлено с приоритетом 32765. Нам это вполне подходит (хотя можем указать приоритет явным образом, например 100):

# ip rule add prio 100 fwmark 1 lookup vpnrouting

ВАЖНОЕ ЗАМЕЧАНИЕ!
Не забудьте проверить состояние rp_filter

Для нормальной работы, результат должен быть либо 0, либо 2. Смысл данного фильтра в следующем. Когда пакет приходит на интерфейс, ядро проверяет для него обратный маршрут. И если ответ предполагает отправку через другой интерфейс, а не тот же самый, то он считается мусорным и сбрасывается. Структура, которую мы настроили, не позволяет ядру корректно определить маршрут через тот же интерфейс. Поскольку на данном этапе он еще не маркирован, и предполагает отправку через default gateway таблицы main.

Для более полной информации, стоит прочитать что такое rp_filter, для чего он нужен и смысл значений его параметров. Я рекомендую переводить его в значение 2 для интерфейса tun0, и 1 для всех остальных.

Источник

Top 3 способа передачи маршрутов удаленным VPN-клиентам

1. Рекомендуем использовать классовую маршрутизация, в таком варианте никакие маршруты на клиенте прописывать не надо, при подключение к VPN вы получите «классовый маршрут» на сеть на впн шлюз т.е 172.16.0.0/16 и 10.0.0.0/8.

Итог если сеть распланирована верно, пример:

Читайте также:  File filters in linux

Переводим адресацию сетей на диапазон 172.16.0.0/16 (mask 255.255.0.0). Получается сеть класса “B”. Внутри нее планируем подсети:

1. 172.16.1.0/24 (mask 255.255.255.0) – клиенты VPN

2. 172.16.10.0/24 (mask 255.255.255.0) – головной офи с

3. 172.16.20.0/24 (mask 255.255.255.0) – сеть филиала

4. … и еще 253 подсети по /24 свободны

Если сеть маленькая и вы хотите использовать для сети 192.168.X.0/24, то выход поделить на подсети:

1. 192.168.10.0/25 (mask 255.255.255.128) – сеть офиса

2. 192.168.10.128/25 (mask 255.255.255.128) – клиенты VPN

И тут у вас классовый маршрут будет 192.168.10.0/24 – который отправить на впн сервер.

2. RIP также довольно простой способ, на mikrotik включить в два клика (смотрите в видео), при этом на клиенте не забудьте:

2.1. Включить прослушиватель RIP

2.2. Открыть порт UDP 520 на входящий трафик.

3. IKEv2 можно прокидывать маршруты (все модно и молодежно), но очень сложно настраивать и отлаживать.

Дополнение, если ваша задача только добавить маршрут, VPN сервер вы не администрируете и у вас Windows 10, то есть удобный способ: прописать статический маршрут для любого VPN интерфейса ,который будет поднят VPN тунель с указанным именем:

Add-VpnConnectionRoute -ConnectionName «VPN_NAME» -DestinationPrefix 192.168.111.0/24 –PassThru

Remove-VpnConnectionRoute -ConnectionName VPN_NAME -DestinationPrefix 192.168.111.0/24 -PassThru

Источник

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

Источник

Оцените статью
© 2023 Posetke
Adblock
detector