LINUX.ORG.RU
решено Форум — Admin  

перенос OpenVPN

 , , ,


0

2

здравствуйте имеется следующая задача: с машины на FreeBSD 7 перенести OpenVPN на машину с Debian 9 или, если совсем не можно, на машину с FreeBSD 11.2. на новой машине с Debian 9 установлен OpenVPN, со старой машины перенесён конфиг и секретный ключ. машина, из этой же сети vpn на другом конце - пингуется. а вот нужная машина, которая расположена уже в локальной подсети 192.168.0.5 - не пингуется, хотя я прописываю маршрут на vpn машине до той подсети. теперь по-порядку: имеем две машины в сети vpn: 10.4.0.2 - на моей стороне, 10.4.0.1 - на другой стороне. моя машина смотрит в локальную подсеть - 192.168.7.0, удалённая машина смотрит в подсеть - 192.168.0.0. пинг между 10.4.0.2. и 10.4.0.1 идёт замечательно, а в подсеть 192.168.0.0 - нет. ответы не приходят. я собрал некоторые конфиги с машины FreeBSD 7 и прилагаю их в виде ссылки на текстовый файл, тк не разобрался здесь со спойлерами. https://yadi.sk/i/PWCG0NM13ZQkvN

отличия на машине с Debian 9: только один интерфейс tap и нет вот такой строки - 10.4.0.1 00:bd:c6:1b:00:03 UHLW 2 138 tap0 1183

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

upd mac адреса tap не подделывал, есть мысль, что файрвол на том конце зарубает неизвестные mac-и

upd подделка маков не помогла



Последнее исправление: tailgunner (всего исправлений: 3)
← Миграция домена в днс
Подскажите резолвер DNS →

// 192.168.7.0->10.4.0.2->10.4.0.1->192.168.0.5

На машине к которой ты подключаешься (которая находится в подсети 192.168.0.0): 

iptables -t nat -A POSTROUTING -o eth+ -s 10.4.0.2/24 -j MASQUERADE

Убедится что других[мешающих] правил нет: 

iptables -t nat -nvL
iptables -t filter -nvL

Включен форвардинг: 

cat /proc/sys/net/ipv4/ip_forward
должно вернуть 1, иначе cat 1 > /proc/sys/net/ipv4/ip_forward

Aber ★★★★★
()

связываться с админом на том конце vpn нет ни малейшего желания

Думаю это он налажал, все что я перечислил относится к удаленной машине.

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

в том-то и соль: нет доступа на машины на той стороне. если я запускаю машину с FreeBSD 7(старая рабочая машина с впн), то обмен с подсетью 192.168.0.0 идёт нормально. проблема именно в новой машине Debian с OpenVPN на моей стороне.

man8531
() автор топика

с машины на FreeBSD 7 перенести OpenVPN на машину с Debian 9

Так на FreeBSD все работает? Тогда это я неправильно прочитал исходные данные. Понятия не имею в чем причина, тебе поможет tcpdump: 

sudo tcpdump -vvv -n -i tun0
Где tun0 это интерфейс тунеля. Если пакеты успешно уходят в тунель, но ответ не приходит, то странно что на FreeBSD работало.

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

tcpdump -vvv -n -i tap0 tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes 10:13:59.634615 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::4028:58ff:fe66:edfe > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16 source link-address option (1), length 8 (1): 42:28:58:66:ed:fe 0x0000: 4228 5866 edfe ^C 1 packet captured 1 packet received by filter 0 packets dropped by kernel

вот ещё данные с новой машины на Debian 9 ip route default via 192.168.7.1 dev ens18 onlink 10.4.0.0/24 dev tap0 proto kernel scope link src 10.4.0.2 192.168.0.0/24 via 10.4.0.1 dev tap0 192.168.7.0/24 dev ens18 proto kernel scope link src 192.168.7.6

ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 56:bc:91:db:41:3d brd ff:ff:ff:ff:ff:ff inet 192.168.7.6/24 brd 192.168.7.255 scope global ens18 valid_lft forever preferred_lft forever inet6 fe80::54bc:91ff:fedb:413d/64 scope link valid_lft forever preferred_lft forever 3: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/ether 42:28:58:66:ed:fe brd ff:ff:ff:ff:ff:ff inet 10.4.0.2/24 brd 10.4.0.255 scope global tap0 valid_lft forever preferred_lft forever inet6 fe80::4028:58ff:fe66:edfe/64 scope link valid_lft forever preferred_lft forever

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

продублирую более читабельно 

ip route
default via 192.168.7.1 dev ens18 onlink 
10.4.0.0/24 dev tap0 proto kernel scope link src 10.4.0.2 
192.168.0.0/24 via 10.4.0.1 dev tap0 
192.168.7.0/24 dev ens18 proto kernel scope link src 192.168.7.6

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 56:bc:91:db:41:3d brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.6/24 brd 192.168.7.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80::54bc:91ff:fedb:413d/64 scope link 
       valid_lft forever preferred_lft forever
3: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/ether 86:d1:f8:25:a0:b3 brd ff:ff:ff:ff:ff:ff
    inet 10.4.0.2/24 brd 10.4.0.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::84d1:f8ff:fe25:a0b3/64 scope link 
       valid_lft forever preferred_lft forever

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

Без форматирования очень тяжело понять. В tcpdump там только один пакет icmp6, т.е. пинг по ipv6, а все настройки которые мы обсуждаем касаются ipv4, ну и как понять какой ip был в src_ip? 

ip route 
default via 192.168.7.1 dev ens18 onlink 
10.4.0.0/24 dev tap0 proto kernel scope link src 10.4.0.2 
192.168.0.0/24 via 10.4.0.1 dev tap0 
192.168.7.0/24 dev ens18 proto kernel scope link src 192.168.7.6

По моему не хватает как минимум что-то вроде

Сравни маршруты (route) во Freebsd и Debian при включенном туннеле, посмотри в чем разница, мне кажется там ошибка.

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

маршрут в дебиан 

ip route
default via 192.168.7.1 dev ens18 onlink 
10.4.0.0/24 dev tap0 proto kernel scope link src 10.4.0.2 
192.168.0.0/24 via 10.4.0.1 dev tap0 
192.168.7.0/24 dev ens18 proto kernel scope link src 192.168.7.6

маршрут из фрибсд 

netstat -r
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            Dlink-Router.Dlink UGS         0     8608    rl0
10.4.0.0           link#5             UC          0        0   tap0
10.4.0.1           00:bd:c6:1b:00:03  UHLW        2      138   tap0   1183
localhost          localhost          UH          0        0    lo0
192.168.0.0        10.4.0.1           UGS         0     6931   tap0
192.168.7.0        link#2             UC          0        0    rl0
Dlink-Router.Dlink 1c:5f:2b:83:f9:e8  UHLW        2       17    rl0   1182
192.168.7.6        00:05:5d:4d:ac:87  UHLW        2        0    lo0


Internet6:
Destination        Gateway            Flags      Netif Expire
localhost          localhost          UHL         lo0
fe80::%lo0         fe80::1%lo0        U           lo0
fe80::1%lo0        link#4             UHL         lo0
ff01:4::           fe80::1%lo0        UC          lo0
ff02::%lo0         fe80::1%lo0        UC          lo0

у меня к этому непонимание 

10.4.0.1           00:bd:c6:1b:00:03  UHLW        2      138   tap0   1183
как я понял, он создаётся сам. у него флаг, точно такой же, как у подключаемых машин в этот тоннель. как у этой, например 
pc7057.Dlink       1c:1b:0d:c2:78:fa  UHLW        1     5757    rl0    916

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

ip route вроде выглядит правильно (но я не админ, могу не увидеть), потому я бы все пинги порверял через tcpdump, и посмотрел что нет ли правил фильтрующих пакеты iptables -nvL, если есть правила смотреть после пингов увеличение счетчиков pkts и bytes рядом с DROP, REJECT.

Больше не подскажу, не знаю.

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

Самое правильное это сначала по5ять где проблема

1. Включить маршрутизацию

2. Отключить nat/маскарад

3. Запустить tcpdump -eni any '(ip proto 1)

4. Запустить пинг с дебиана и посмотреть

5. Запустить пинг с компа локалки и посмотреть

И гарантирую, что ЕСЛИ (весьма маловероятно) маскарад и потребуется, то только на интерфейсах tun/tap

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

Маршрутизацию на дебиане включена? sysctl net.ipv4.ip_forward в смысле

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

man8531
() автор топика
Ответ на: комментарий от Nastishka

Я не догадался что форвардинг нужно еще и на клиенте включать.

Я что-то торможу, а где там форвард нужен если пинговать с debian, или debian используется как шлюз и пинговалось из подсети?

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

Об этом в первом сообщении писали уже.

прошу пардону, но я слаб во всех этих вражеских языках, для меня маршрутизация - роднее.

man8531
() автор топика
Ответ на: комментарий от Aber

дебиан - шлюз. пинги делал со шлюза, а потом из подсети. ещё столкнулся с тем, что нет, или я плохо искал, простого решения прописывания статического маршрута. в винде всё просто: route add -p и маршрут навечно на машине и корректно стартует. в дебиане же нужно прописывать в файле interfaces и то скрипт с с отсрочкой запуска команды, тк иетфейс не успевает подняться, а команда добавления маршрута отработала.

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

Не знаю за ваш дебиан и прочее убунту, а у нас в центосе /etc/sysconfig/network-scripts/route-<ifname> и всё работает, так что ССЗБ

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

тут дело не в дебиане оказалось, а в proxmox. если на самом дебиане, куда проксмокс установлен, та же загрузка правил иптаблес отрабатывает корректно, а вот уже на виртуальной машине, с тем же дебианом - нет. совсем ложит сеть.

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

моя ошибка. переделал заново и заработало.

man8531
() автор топика
Ответ на: комментарий от digitaldark

нет, с контейнерами я пока не знакомился. не стал рисковать и ставил независимые машины. пока доволен.

man8531
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Миграция домена в днс
Admin
Подскажите резолвер DNS →