LINUX.ORG.RU
ФорумAdmin

Не перенаправляются пакеты openvpn

 


2

1

Вот схема того что есть

                          ------------
         ---------------->| INTERNET |<------NAT--------- 
         |                ------------                  |
 ----------------------         ↑               ---------------------      
 |      VPS1          |         |               |  WIN7 HOME        |
 | eth0 46.101.222.40 |  ---------------------  | gateway 10.8.50.1 |
 | openvpn client2    |  |      VPS2         |  | openvpn client1   | 
 | tun0 10.8.50.50    |  | eth0 185.40.31.56 |  | ip: 10.8.50.30    |
 ----------------------  | openvpn server    |  ---------------------
                         | tun0 10.8.50.1    |
                         ---------------------
Требуется трафик openvpn client1 перенаправить через openvpn client2. На домашнем компьютере выполняю ping 8.8.8.8 На VPS2 и VPS1 firewall отключены полностью На VPS2 добавлены правила
ip add default 10.8.50.50 table 120
ip rule add from 10.8.50.30 table 120
Пакеты приходят на VPS2

root@vps2:~# tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
11:59:50.456230 IP 10.8.50.30 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 26, length 40
11:59:50.456300 IP 10.8.50.1 > 10.8.50.30: ICMP redirect google-public-dns-a.google.com to host 10.8.50.50, length 68
11:59:50.456308 IP 10.8.50.30 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 26, length 40
11:59:54.974659 IP 10.8.50.30 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 27, length 40
11:59:54.974693 IP 10.8.50.30 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 27, length 40
11:59:59.975197 IP 10.8.50.30 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 28, length 40
11:59:59.975232 IP 10.8.50.30 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 28, length 40
12:00:04.975591 IP 10.8.50.30 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 29, length 40
12:00:04.975628 IP 10.8.50.30 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 29, length 40

Но на VPS1 полная тишина :(


Самое очевидное решение сделать на домашнем компьютере gataway 10.8.50.50 не работает, так как пакеты всё равно приходят на openvpn сервер и дальше никуда не идут.

nefton ()

Мой любимый комментарий, «пользуйтесь поиском». Здесь были темы, предел не более года.

anc ★★★★★ ()
Ответ на: комментарий от anc

Итак, пару недель попыток и поисков дали результаты.

Вот тема где эта проблема обсуждалась. Там есть ответ как но нет ответа почему.

1. Пакеты openvpn имеют очень мало общего с пакетами ethernet!
1.1. Несмотря на конфиг сервера «client-to-client» пакеты от клиента к клиенту проходят исключительно в том случае, когда конечный получатель в пакете это тот самый клиент.
То-есть никак нельзя указать другого клиента в качестве gateway.
1.2. Некоторые пакеты всё же можно «завернуть» на клиента с помощью команды сервера iroute.
Да да, несмотря на то, что находится она в серверном конфиге соответствующего клиента, клиент о ней ничего не знает, это исключительно для сервера.
И работает этот механизм исключительно по адресу назначения пакета (не по его источнику или содержимому)
Притом ещё довольно кривовато. Например это работает:

iroute 1.0.0.0 255.0.0.0
iroute 2.0.0.0 255.0.0.0
iroute 3.0.0.0 255.0.0.0
. . . . . . 
iroute 254.0.0.0 255.0.0.0
iroute 255.0.0.0 255.0.0.0
А вот это нет:
iroute 0.0.0.0 0.0.0.0
И это тоже нет
iroute 0.0.0.0 128.0.0.0
iroute 128.0.0.0 128.0.0.0
Ну то мелочи.

1.3. Перенаправление openvpn пакетов с помощью ip rule не работает никак.

ip add default 10.8.50.50 table 120
ip rule add from 10.8.50.30 table 120
Думаю всё по той же причине, что нельзя openvpn пакетам присвоить gateway, так как у openvpn интерфейсов (tun0) нет никакого MAC адреса.

Ну и в заключение краткие выводы.
Буду ждать и надеяться когда появится нормальное решение виртуальных сетей c gateway, MAC адресами, гибкими политиками управления пакетами.
Ну а пока добро пожаловать в этот костыльный мир :)

nefton ()
Ответ на: комментарий от nefton

По порядку, для чего нужен iroute. Представьте себе у вас н-цать клиентов и за каждым н-цать сетей. Простой пример клиент1 за ним сеть 192.168.1.0/24, клиент2 за ним сеть 192.168.2.0/24, клиент3 за ним сеть 192.168.3.0/24. Сервер (обратите внимание это один интерфейс) получает пакет от 192.168.1.1 для 192.168.2.1, на каком основании он должен принять решение какому клиенту его отправлять, второму или третьему? Вот для этого и нужен iroute, на основании которого сервер принимает решение кому отправить пакет.
Почему не работает iroute 0.0.0.0 0.0.0.0 - думаю догадаетесь сами.

Насчет iptables, оно работает и это есть в мане, для этого надо убрать client-to-client, но не забыть запушить вручную роут на сеть ovpn. Да, и связка iptables + ip ru + ip ro вполне работает, но iroute по любому нужен.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 2)
Ответ на: комментарий от anc

Сервер (обратите внимание это один интерфейс) получает пакет от 192.168.1.1 для 192.168.2.1, на каком основании он должен принять решение какому клиенту его отправлять, второму или третьему?

На основании ip route и ip rule? Как и все остальные пакеты. Но он этого не делает.

Почему не работает iroute 0.0.0.0 0.0.0.0 - думаю догадаетесь сами.

Не могу догадаться, так как вместо этой строки прописываю 255(256) строк. Хорошо что VPS с сервером резиновый, а вот на роутере Linksys WRT54GL c ddwrt например.... Для этого конфига нехватило бы памяти чтоб просто сохранить эти 255 строк.

Да, и связка iptables + ip ru + ip ro вполне работает

Нет не работает. 1й пост. Пакеты не перенаправляются.

iptables работает. Но это firewall он может только пропустить или отклонить пакет. Ну или сделать ему SNAT MASQUERADE. iptables не может отправить пакет на другой комп. Этим занимается ip route и ip rule.

nefton ()
Ответ на: комментарий от nefton

На основании ip route и ip rule? Как и все остальные пакеты. Но он этого не делает.

Мне показалось я вам все расписал. ovpn это один сервер, ну тупо «черная коробка» которая имеет всего один интерфейс в системе, и к которой конектится куча клиентов. Вот как «черная коробка» может узнать кроме себя самой какому клиенту отправить тот или иной пакет?

Не могу догадаться, так как вместо этой строки прописываю 255(256) строк.

Все-таки не 256

Нет не работает. 1й пост. Пакеты не перенаправляются.

Я не про ваш случай, возможно неправильно описал. Все можно использовать и ip и iptables для гибкого роутинга через ovpn, но не в лоб как вы написали, т.е. их использование в связке с ovpn работает, просто надо понимать что делаем. Инфа 146% сам пользую для некоторых извращенных случаев (повторюсь не ваш случай и iroute нужен). И обратите внимание, client-to-client надо убрать.

anc ★★★★★ ()
Ответ на: комментарий от nefton

iptables работает. Но это firewall он может только пропустить или отклонить пакет. Ну или сделать ему SNAT MASQUERADE. iptables не может отправить пакет на другой комп. Этим занимается ip route и ip rule.

А еще установить метку, для последующей обработки в iproute2

anc ★★★★★ ()
Ответ на: комментарий от anc

Мне показалось я вам все расписал. ovpn это один сервер, ну тупо «черная коробка» которая имеет всего один интерфейс в системе, и к которой конектится куча клиентов. Вот как «черная коробка» может узнать кроме себя самой какому клиенту отправить тот или иной пакет?

Вот и я о том же. Эта «чёрная коробка» сама по себе. Я потратил очень много времени чтоб понять что виртуальные интерфейсы «tun0» это не совсем интерфейс как «eth0», есть существенные отличия.

Все-таки не 256

Не думаю что кто-то видел пакет с адресом назначения 0.х.х.х Мой сервер точно не видел ). Могу конечно дописать iroute 0.0.0.0 255.0.0.0 Но что изменится?

И обратите внимание, client-to-client надо убрать.

Поэксперементирую.

А еще установить метку, для последующей обработки в iproute2

Думаете если он не перенаправляет без метки то перенаправит с меткой? Отфильтрует - да. Перенаправит - нет.

nefton ()
Ответ на: комментарий от nefton

Вот и я о том же. Эта «чёрная коробка» сама по себе. Я потратил очень много времени чтоб понять что виртуальные интерфейсы «tun0» это не совсем интерфейс как «eth0», есть существенные отличия.

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

Не думаю что кто-то видел пакет с адресом назначения 0.х.х.х Мой сервер точно не видел ). Могу конечно дописать iroute 0.0.0.0 255.0.0.0 Но что изменится?

Опять не поняли, ВСЕ там не нужны, как минимум исключения сетей других клиентов и свой же внутренней.

Поэксперементирую.

В мане все очень хорошо описано. Я многим об этом говорю.

Думаете если он не перенаправляет без метки то перенаправит с меткой? Отфильтрует - да. Перенаправит - нет.

Мы вроде говорили про связку iptables + iproute2. Я вам уже несколько раз написал, оно и для ovpn работает. Другой вопрос как готовите, надо понимать работу ovpn и тогда iptables + iproute2 могут оказать вполне хорошую помощь. Во всяком случае у меня работает не первый год и без iptables + iproute2 было бы очень «не удобно».

anc ★★★★★ ()
Ответ на: комментарий от anc

Вот как «черная коробка» может узнать кроме себя самой какому клиенту отправить тот или иной пакет?

Для Linux-Linux это никогда не было проблемой, потому что это ничего дополнительно не требовало. Выставляем маску удаленной сети и адрес удаленный должен быть с той удалённой сети и всё работало. Потому что point-to-point интерфейсы они точечные локально, а удалённо можно на Linux юзать и с маской. А так как локально адреса вообще не нужны, то милое дело ставить их unnumbered из локального эзернета.

vodz ★★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от anc

Эмм, вроде речь про ovpn, не ?

А какая разница? Там же не свой IP стек и/или программный сетевой интерфейс.

vodz ★★★★★ ()
Ответ на: комментарий от anc

Но то чо вы написали не более чем вброс, в рамках задачи.

Я отвечал на ваш конкретный коментарий.

В рамках задачи у ТСа вроде всё правильно - пришедшие пакеты из tun1 идут по src-рутингу в tun2. Обратно пойдут своим ходом без извращений, по dst. Не понятно только, делает ли masquerade vps1, по логу то как раз вроде и нет.

vodz ★★★★★ ()

а форвардинг включен на VPS-1 ? И правило SNAT там еще нужно добавить...

ving2 ()
Ответ на: комментарий от vodz

В рамках задачи у ТСа вроде всё правильно - пришедшие пакеты из tun1 идут по src-рутингу в tun2.

«Але, секундочку, я записываю» (с)
Где вы увидели два интерфейса ?

anc ★★★★★ ()
Ответ на: комментарий от anc

Где вы увидели два интерфейса ?

Где где... в $%^де. Там два туннеля у сервера. То что ТС изобразил на «картинке» tun0, так это вопросы к нему.

vodz ★★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vodz

Пятница? У ТС один, подчеркиваю один сервер с одним интерфейсом. А сколько к нему тунелей уже без разницы, хоть сотня. Так что на картинке он все правильно отобразил.
Но вы натолкнули на мысль, с топологией subnet согласно картинки, возможно и взлетит.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

один сервер с одним интерфейсом.

Я тоже сначала подумал что, ТС забыл указать tun1 на сервере. Обычно просто подымают по другому, на 1 серваке поднимают и клиента и сервера. А на другом сервера...

ving2 ()
Последнее исправление: ving2 (всего исправлений: 1)
Ответ на: комментарий от ving2

Стоило уехать на выходные... а тут... ))) Изображено всё правильно. На сервере(VPS2) один интерфейс tun0, и там поднят openvpn сервер.

На другом «сервере» (VPS1) поднят openvpn client. Надо именно так, так как впоследствии его роль будет выполнять роутер за NATом без внешнего айпи или проброски портов. Обычный домашний роутер (ddwrt). И там тоже один интерфейс tun0.

На сервере как видно один виртуальный интерфейс tun0

root@VPS2:~# ifconfig
eth0      Link encap:Ethernet  HWaddr fa:16:3e:80:5f:2b
          inet addr:185.40.31.56  Bcast:185.40.31.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2147518 errors:0 dropped:0 overruns:0 frame:0
          TX packets:372698 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:219295069 (219.2 MB)  TX bytes:77819150 (77.8 MB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:25770 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25770 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2226528 (2.2 MB)  TX bytes:2226528 (2.2 MB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.50.1  P-t-P:10.8.50.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1904 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:440424 (440.4 KB)  TX bytes:1276 (1.2 KB)
На клиенте (VPS1) тоже самое.

nefton ()
Ответ на: комментарий от nefton

Ну и чтоб ешё раз продемонстрировать что роутингом openvpn пакетов занимается openvpn а не линукс вот некоторые логи.

Как видно линукс ничего не слышал ни про какое перенаправление пакетов.

root@VPS2:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         185.40.31.1     0.0.0.0         UG    0      0        0 eth0
10.8.50.0       *               255.255.255.0   U     0      0        0 tun0
169.254.169.254 185.40.31.2     255.255.255.255 UGH   0      0        0 eth0
185.40.31.0     *               255.255.255.0   U     0      0        0 eth0
185.111.219.0   *               255.255.255.0   U     0      0        0 eth0
212.8.234.0     *               255.255.255.0   U     0      0        0 eth0

А вот openvpn - очень даже. (Хоть имхо и очень криво)

root@VPS2:~# cat /etc/openvpn/openvpn-status.log
OpenVPN CLIENT LIST
Updated,Sun Sep  3 04:36:22 2017
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client_kv2,95.133.1.67:10004,203599,217805,Sat Sep  2 19:45:49 2017
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
159.0.0.0/8,client_kv2,95.133.1.67:10004,Sat Sep  2 19:45:51 2017
87.0.0.0/8,client_kv2,95.133.1.67:10004,Sat Sep  2 19:45:51 2017
168.0.0.0/8,client_kv2,95.133.1.67:10004,Sat Sep  2 19:45:51 2017
206.0.0.0/8,client_kv2,95.133.1.67:10004,Sat Sep  2 19:45:51 2017
54.0.0.0/8,client_kv2,95.133.1.67:10004,Sat Sep  2 19:45:51 2017
240.0.0.0/8,client_kv2,95.133.1.67:10004,Sat Sep  2 19:45:51 2017
...
И дальше ещё таких строк 255. Почему то в случайном порядке. Но я привык уже :-)

nefton ()
Ответ на: комментарий от nefton

Ну и да. На VPS1 обычный маскарадинг.

iptables -t nat -A POSTROUTING -s 10.8.50.0/24 -j MASQUERADE

nefton ()
Ответ на: комментарий от anc

У ТС один, подчеркиваю один сервер с одним интерфейсом.

Оно и видно, у tun0 у него что локальный, что удалённый адрес один и тот же. Как оно вообще у него что-то работает - не понятно.

А сколько к нему тунелей уже без разницы, хоть сотня.

Что, действительно в openvpn реализовали программный стек, которому не нужны ядерные адреса на интерфейсах?

vodz ★★★★★ ()
Ответ на: комментарий от vodz

Что, действительно в openvpn реализовали программный стек, которому не нужны ядерные адреса на интерфейсах?

Если я вас правильно понял и вы поняли то что описано выше. Отвечу да. Вообще говоря ovpn это userspace.

anc ★★★★★ ()
Ответ на: комментарий от anc

Вообще говоря ovpn это userspace.

Не стоит так разбрасываться строгими терминами, userspace там инкапсуляция туннеля, как и все userspace туннели, но не рутинг.

vodz ★★★★★ ()
Ответ на: комментарий от vodz

Оно и видно, у tun0 у него что локальный, что удалённый адрес один и тот же. Как оно вообще у него что-то работает - не понятно.

А вот тут вы правы. Конфигов то мы и не увидели, так что это может быть как правдой так и ошибкой.

anc ★★★★★ ()
Ответ на: комментарий от vodz

Однако своих клиентов ovpn при топологии net30 роутит сам, до ядра эти пакеты не доходят (точнее если убрать client-to-client дойдут) но роутингом внутри себя все равно будет заниматься сам ovpn. И причина уже описана мной выше.

anc ★★★★★ ()
Ответ на: комментарий от anc

сам не пробовал, но вроде должно работать,

Мало того, что это не только должно работать, оно работает и много-много лет назад, когда инет был платный по трафику, я делал схему ТСа, сильно усложнённую, когда от каждого линка филиала выжирался бесплатный лимит инета за абонентку, автоматически переключался default gw после подсчёта сожранного трафика :)

vodz ★★★★★ ()
Ответ на: комментарий от vodz

Ну если быть честным то subnet в винду не «много-много лет назад» завезли.
ЗЫ Воспримите как шутку. У вас 3.5-года недавно, так что да, наверное «много-много лет назад» :)

anc ★★★★★ ()
Ответ на: комментарий от anc

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

vodz ★★★★★ ()
Ответ на: комментарий от anc

Но вы натолкнули на мысль, с топологией subnet согласно картинки, возможно и взлетит.

Фух, думал надо опять поднимать для теста subnet 2 сервера.

(Не хотелось останавливать работающую схему)

Но оказывается subnet у меня и так прописан там.

root@vps2:~# cat /etc/openvpn/server.conf
port 1194
topology subnet
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh1024.pem
server 10.8.50.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
client-to-client
keepalive 10 60
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log         openvpn.log
verb 3
push "ping 10"
push "ping-restart 60"
push "persist-tun"
push "persist-key"

nefton ()
Ответ на: комментарий от nefton

/etc/openvpn/ccd/client_vps1

ifconfig-push 10.8.50.100 255.255.255.0

iroute 0.0.0.0 255.0.0.0
iroute 1.0.0.0 255.0.0.0
iroute 2.0.0.0 255.0.0.0
iroute 3.0.0.0 255.0.0.0
...
iroute 255.0.0.0 255.0.0.0

/etc/openvpn/ccd/client_win7

ifconfig-push 10.8.50.30 255.255.255.0
push "redirect-gateway def1"

nefton ()
Ответ на: комментарий от anc

В кошках был ovpn?

Он тогда везде был глючный. Я просто вспомнил, чем мне эта задача (default одного филиала на другой, а не в центр) напоминает. Ясен пень - отдаленно, так как там был src-рутинг с кучей кривых скриптов по подсчёту трафика и правки конфигов с route-map и nat-ов.

vodz ★★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от nefton

Для синтетики варианты (именно разные варианты).
1. Заменить на tap (он всетаки L2).
2. Для винды: убрать push «redirect-gateway def1», и вручную прописать роуты не на 10.8.50.1 а на 10.8.50.50 (точнее вы отошли от схемы и видимо это 10.8.50.100)
ЗЫ Про client-to-client я уже писал, не большая проблема его убрать.

anc ★★★★★ ()
Ответ на: комментарий от anc

Для винды: убрать push «redirect-gateway def1», и вручную прописать роуты не на 10.8.50.1 а на 10.8.50.50 (точнее вы отошли от схемы и видимо это 10.8.50.100)

Да, перепутал. Просто схема уже работает и переехала с тестового vps на живой роутер в реальной жизни :)

А про gateway вручную - это первое и самое логичное что я опробовал! (Второе сообщение тут кстати) Но это НЕ работает с openvpn. Прям совсем. И это не просто не работает, а известна и причина. Я ловил уходящие пакеты wiresharkом и рассматривал их с лупой. Так вот gateway - это ничто иное как MAC адрес шлюза. Тык. А теперь смотрим MAC нашего виртуального tun0 интерфейса... 00-00-00-00-00-.... Короче его попросту нету.

Про client-to-client я уже писал, не большая проблема его убрать.

Я потеряю ssh доступ к роутеру в другом городе(vps1) через putty по адресу 10.8.50.50. Думаю это будет единственный эффект. MAC адреса у интерфейсов врятли от этого появятся, а значит самая здравая идея с gateway на win7 - про прежнему не заработает. Как думаю и идея с

ip add default 10.8.50.50 table 120
ip rule add from 10.8.50.30 table 120
На сервере. Опять по той же причине. Само понятие gateway не совместимо с openvpn. Все пакеты приходят на сервер, независимо ни от чего.

Заменить на tap

Поробую попозже. Думаете MAC адрес у интерфейсов от этого появится?

nefton ()
Ответ на: комментарий от nefton

Да, перепутал. Просто схема уже работает и переехала с тестового vps на живой роутер в реальной жизни :)

Первое и главное, работает не трогать. :)

Далее как писал выше только синтетика перед внедрением!!! Т.е. на виртуалках, раз вы уже в прод перенесли.

А про gateway вручную - это первое и самое логичное что я опробовал! (Второе сообщение тут кстати)

Я про винду написал и не нашел такого ответа.

Так вот gateway - это ничто иное как MAC адрес шлюза. Тык.

Не внимательно читаем, там ниже vodz тоже правильно написал Gateway помогите понять (комментарий)
Так что по поводу mac не совсем верно. У меня может быть tun на который я зарулю что-то, и он примет, но проблема в том вернут ли мне ответ... тут уже другая проблема с роутингом.
У вас на tun висит подсеть 10.8.50.0/24 и через нее вы можете роутить пакеты.

anc ★★★★★ ()
Ответ на: комментарий от anc

У меня может быть tun на который я зарулю что-то, и он примет.

Да, он то примет. Но кто он и что примет? Он - это openvpn сервер. И никто другой. Что примет? Пакет. Возьмём для примера коротенький icmp пакет. Дак вот же он:

root@vps2:~# tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
11:59:50.456230 IP 10.8.50.30 > 8.8.8.8: ICMP echo request, id 1, seq 26, length 40
Там есть конечная цель: 8.8.8.8
И отправитель: 10.8.50.30
Никакого gateway там нет! Думал там в MAC нули - а нет. Там вообще MAC никакого нету! То есть просто нету.

У вас на tun висит подсеть 10.8.50.0/24 и через нее вы можете роутить пакеты.

В этом то и есть мой основной посыл будущим изыскателям. Что сеть 10.8.50.0/24 это никакая не «просто подсеть». Там нет Ethernet, там нет MAC, и соответственно нет понятия gateway вообще в принципе. Это по сути интерфейс точка-точка. А ни какая не «подсеть» даже виртуальная.

Например самое обычное стандартное подключение через openvpn для просмотра чего-то нецензурного... Что будет если в винде поменять default gateway на другой? Скажем был 10.8.0.1 А мы его принудительно меняем на 10.8.0.123 ? Так вот ничего не будет :) Всё будет работать как и работало. Единственное если поставить gateway ем свой адрес - то работать перестаёт.

nefton ()
Ответ на: комментарий от nefton

Не поняли.
1. Для винды: убрать push «redirect-gateway def1» из ccd
2. После подключения на винде добавьте роутинг например для 8.8.8.8 через 10.8.50.100 (полностью команду не помню но там что-то вида route add ip mask gw, вроде по /? показывает синтаксис) и главное что бы маскарад у 10.8.50.100 был запущен (но это я так понимаю и так уже есть, раз у вас работает)
Т.е. получиться винда будет слать пакеты не к 10.8.50.1 а к второму клиенту 10.8.50.100.
Это для теста на одном хосте (8.8.8.8) что бы не трогать уже занатного клиента 10.8.50.100.

anc ★★★★★ ()
Ответ на: комментарий от anc

Я все то к тому что уже две темы чуть не подряд пробежало, правда без ответа, где предполагаемо win7 редирект роута не понимает.

anc ★★★★★ ()
Ответ на: комментарий от anc

Не поняли. Т.е. получиться винда будет слать пакеты не к 10.8.50.1 а к второму клиенту 10.8.50.100

Это было сделано с самого начала. Перечитайте тему. Пакеты не идут к 10.8.50.100 Пакеты всё равно идут на 10.8.50.1

nefton ()
Ответ на: комментарий от anc

Не знаю чем это поможет.

C:\Users\Nefton>route print -4
===========================================================================
Список интерфейсов
 14...00 ff a2 bc b1 c5 ......TAP-Windows Adapter V9
 11...00 1d 92 ee 5e 52 ......Сетевой контроллер NVIDIA nForce
 18...0a 00 27 00 00 12 ......VirtualBox Host-Only Ethernet Adapter
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP
 13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 15...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP #2
 17...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP #3
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.127     21
          0.0.0.0        128.0.0.0       10.8.0.150       10.8.50.30     21
          0.0.0.0        128.0.0.0        10.8.50.1       10.8.50.30     20
        10.8.50.0    255.255.255.0         On-link        10.8.50.30    276
       10.8.50.30  255.255.255.255         On-link        10.8.50.30    276
      10.8.50.255  255.255.255.255         On-link        10.8.50.30    276
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
        128.0.0.0        128.0.0.0        10.8.50.1       10.8.50.30     20
     185.40.31.56  255.255.255.255      192.168.1.1    192.168.1.127     20
      192.168.1.0    255.255.255.0         On-link     192.168.1.127    276
    192.168.1.127  255.255.255.255         On-link     192.168.1.127    276
    192.168.1.255  255.255.255.255         On-link     192.168.1.127    276
     192.168.56.0    255.255.255.0         On-link      192.168.56.1    266
     192.168.56.1  255.255.255.255         On-link      192.168.56.1    266
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     192.168.1.127    276
        224.0.0.0        240.0.0.0         On-link        10.8.50.30    276
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     192.168.1.127    276
  255.255.255.255  255.255.255.255         On-link        10.8.50.30    276
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    266
===========================================================================
Постоянные маршруты:
  Отсутствует

Пару хитрых движений... и всё по прежнему работает

C:\Users\Nefton>route change 0.0.0.0 mask 0.0.0.0 10.8.50.222
 ОК

C:\Users\Nefton>route delete 0.0.0.0 128.0.0.0
Сбой удаления маршрута: Элемент не найден.


C:\Users\Nefton>route delete 0.0.0.0 mask 128.0.0.0
 ОК

C:\Users\Nefton>route print -4
===========================================================================
Список интерфейсов
 14...00 ff a2 bc b1 c5 ......TAP-Windows Adapter V9
 11...00 1d 92 ee 5e 52 ......Сетевой контроллер NVIDIA nForce
 18...0a 00 27 00 00 12 ......VirtualBox Host-Only Ethernet Adapter
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP
 13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 15...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP #2
 17...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP #3
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      10.8.50.222       10.8.50.30     21
        10.8.50.0    255.255.255.0         On-link        10.8.50.30    276
       10.8.50.30  255.255.255.255         On-link        10.8.50.30    276
      10.8.50.255  255.255.255.255         On-link        10.8.50.30    276
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
        128.0.0.0        128.0.0.0        10.8.50.1       10.8.50.30     20
     185.40.31.56  255.255.255.255      192.168.1.1    192.168.1.127     20
      192.168.1.0    255.255.255.0         On-link     192.168.1.127    276
    192.168.1.127  255.255.255.255         On-link     192.168.1.127    276
    192.168.1.255  255.255.255.255         On-link     192.168.1.127    276
     192.168.56.0    255.255.255.0         On-link      192.168.56.1    266
     192.168.56.1  255.255.255.255         On-link      192.168.56.1    266
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     192.168.1.127    276
        224.0.0.0        240.0.0.0         On-link        10.8.50.30    276
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     192.168.1.127    276
  255.255.255.255  255.255.255.255         On-link        10.8.50.30    276
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    266
===========================================================================
Постоянные маршруты:
  Отсутствует

anc, почитайте пожалуйста ветку. я очень старался писать свои мысли максимально чётко, использовать разметку, смирился и понял отсутствие возможности добавлять картинки (хотя нарисовал её зарание). Всё для того чтоб потом люди, столкнувшись с похожими проблемами наткнулись на мои посты и сказали где-то спасибо :) Но если я буду слишком часто повторять одно и тоже то эта ветка перерастёт в бардак на 20 страницах.

nefton ()
Ответ на: комментарий от nefton

Начну с конца.

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

Возможно был не правильно понят. Вы хорошо описываете.

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

anc ★★★★★ ()
Ответ на: комментарий от anc

Но вот то что я предложил Не перенаправляются пакеты openvpn (комментарий) похоже не попробовали.

Пробовал. Написал это сразу же тут.

nefton: Самое очевидное решение сделать на домашнем компьютере gataway 10.8.50.50 не работает, так как пакеты всё равно приходят на openvpn сервер и дальше никуда не идут.

Затем ответил на Ваш коментарий (пункт 2)

nefton: А про gateway вручную - это первое и самое логичное что я опробовал! (Второе сообщение тут кстати) Но это НЕ работает с openvpn. Прям совсем. И это не просто не работает, а известна и причина. Я ловил уходящие пакеты wiresharkом и рассматривал их с лупой. Так вот gateway - это ничто иное как MAC адрес шлюза. Тык. А теперь смотрим MAC нашего виртуального tun0 интерфейса... 00-00-00-00-00-.... Короче его попросту нету.

Дальше на Ваш коментарий

Я про винду написал и не нашел такого ответа

я ответил может и не конкретно, оттого и неочень понятно. Но всё же.

nefton: Там есть конечная цель: 8.8.8.8 И отправитель: 10.8.50.30 Никакого gateway там нет! Думал там в MAC нули - а нет. Там вообще MAC никакого нету! То есть просто нету.

Дальше Вы опять предложили сменить gateway в винде.

На что я ответил:

nefton: Это было сделано с самого начала. Перечитайте тему. Пакеты не идут к 10.8.50.100 Пакеты всё равно идут на 10.8.50.1

Дальше Вы опять предложили изменить gateway в винде.

Для кого я это всё пишу? Это ж не чат, уважаемый форум.

nefton ()
Ответ на: комментарий от nefton

Ну значит не правильно вас понял. Сделал вывод на основании последнего поста с таблицей роутинга от винды. Извините.

anc ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.