Переход с OpenVPN на WireGuard для объединения сетей в одну сеть L2



    Хотел бы поделиться опытом объединения сетей в трех географически удаленных квартирах, в каждой из которых в качестве шлюза используются роутеры с OpenWRT, в одну общую сеть. При выборе способа объединения сетей между L3 с маршрутизацией подсетей и L2 с бриджингом, когда все узлы сети будут находиться в одной подсети, было отдано предпочтение второму способу, более сложному в настройке, но дающим бОльшие возможности, так как в создаваемой сети планировалось прозрачное использование технологий Wake-on-Lan и DLNA.

    Часть 1: Предыстория


    В качестве протокола для реализации этой задачи изначально был выбран OpenVPN, так как, во-первых, он может создавать устройство tap, которое без проблем добавляется в мост, а во-вторых, OpenVPN поддерживает работу по протоколу TCP, что было также немаловажно, ведь ни в одной из квартир не имелось выделенного IP-адреса, а использовать STUN мне не удалось, так как мой провайдер почему-то блокирует входящие подключения по протоколу UDP из своих сетей, в то время как протокол TCP позволял мне пробросить порт VPN-сервера на арендуемый VPS при помощи SSH. Да, такой подход дает большую нагрузку, так как данные шифруются дважды, но вводить VPS в свою частную сеть я не захотел, так как оставался риск получения третьими лицами контроля над ним, следовательно, иметь в домашней сети такое устройство являлось крайне нежелательным и было решено заплатить за безопасность большим оверхедом.

    Для проброса порта на роутере, на котором планировалось развернуть сервер, была использована программа sshtunnel. Описывать тонкости ее конфигурации не буду — это делается достаточно легко, просто отмечу, что ее задачей был проброс TCP-порта 1194 с роутера на VPS. Далее был настроен сервер OpenVPN на устройстве tap0, которое заводилось в мост br-lan. Проверив подключение к только что созданному серверу с ноутбука — стало понятно, что идея с пробросом порта себя оправдала и мой ноутбук стал членом сети роутера, хотя физически в ней не находился.

    Дело оставалось за малым: нужно было распределить IP-адреса в разных квартирах так, чтобы они не конфликтовали и настроить маршрутизаторы в качестве OpenVPN-клиентов.
    Были выбраны такие IP-адреса маршрутизаторов и диапазоны DHCP-серверов:

    • 192.168.10.1 с диапазоном 192.168.10.2192.168.10.80 для сервера
    • 192.168.10.100 с диапазоном 192.168.10.101192.168.10.149 для маршрутизатора в квартире №2
    • 192.168.10.150 с диапазоном 192.168.10.151192.168.10.199 для маршрутизатора в квартире №3

    Также было необходимо назначить именно эти адреса для маршрутизаторов-клиентов OpenVPN-сервера, путем добавления в его конфигурацию строчки:

    ifconfig-pool-persist /etc/openvpn/ipp.txt 0

    и добавлением следующих строк в файл /etc/openvpn/ipp.txt:

    flat1_id 192.168.10.100
    flat2_id 192.168.10.150
    

    где flat1_id и flat2_id — это имена устройств, указываемые при создании сертификатов для подключения к OpenVPN

    Далее на роутерах были настроены OpenVPN-клиенты, устройства tap0 на обоих были занесены в мост br-lan. На этом этапе казалось, что все в порядке, так как все три сети видят друг друга и работают как единое целое. Однако, выяснилась не очень приятная деталь: иногда устройства могли получить IP-адрес не от своего маршрутизатора, со всеми вытекающими последствиями. По какой-то причине, маршрутизатор в какой-то из квартир не успевал ответить вовремя на DHCPDISCOVER и устройство получало не свой адрес. Я понял, что мне нужно отфильтровать такие запросы в tap0 на каждом из маршрутизаторов, но, как выяснилось, iptables не может работать с устройством, если оно является частью моста и мне на помощь должен прийти ebtables. К моему сожалению, в моих прошивках его не оказалось и пришлось пересобирать образы для каждого устройства. Сделав это и добавив такие строки в /etc/rc.local каждого маршрутизатора проблема была решена:

    ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
    ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
    ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
    ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
    

    Такая конфигурация просуществовала на протяжении трех лет.

    Часть 2: Знакомство с WireGuard


    В последнее время в Интернете все чаще стали говорить о WireGuard, восхищаясь простотой его конфигурации, высокой скоростью передачи, низким пингом при сопоставимой безопасности. Поиск дополнительной информации о нем давал понять, что ни работа в качестве члена моста, ни работа по протоколу TCP им не поддерживается, что наводило меня на мысли о том, что альтернатив OpenVPN для меня по-прежнему нет. Так я откладывал знакомство с WireGuard.

    Несколько дней назад по ресурсам, так или иначе связанным с IT, пролетела новость о том, что WireGuard наконец будет включен в ядро Linux, начиная с версии 5.6. Новостные статьи, как всегда, хвалили WireGuard. Я вновь погрузился в поиски путей замены старого доброго OpenVPN. На этот раз я напоролся на эту статью. В ней говорилось о создании Ethernet-туннеля поверх L3 при помощи GRE. Эта статья вселила в меня надежду. Оставалось неясно что делать с протоколом UDP. Поиск приводил меня к статьям об использовании socat в связке с SSH-туннелем, для проброса UDP-порта, однако, в них отмечалось, что такой подход работает только в режиме одного соединения, то есть работа нескольких VPN-клиентов оказалась бы невозможной. Мне пришла идея поднять VPN-сервер на VPS, а для клиентов настроить GRE, но, как оказалось, GRE не поддерживает шифрование, что приведет к тому, что в случае получения доступа к серверу третьими лицами, в их руках оказывается весь трафик между моими сетями, что меня не устраивало в принципе.

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

    VPN первого уровня:
    VPS является сервером с внутренним адресом 192.168.30.1
    МС является клиентом VPS с внутренним адресом 192.168.30.2
    МК2 является клиентом VPS с внутренним адресом 192.168.30.3
    МК3 является клиентом VPS с внутренним адресом 192.168.30.4

    VPN второго уровня:
    МС является сервером с внешним адресом 192.168.30.2 и внутренним 192.168.31.1
    МК2 является клиентом МС с адресом 192.168.30.2 и имеет внутренний IP 192.168.31.2
    МК3 является клиентом МС с адресом 192.168.30.2 и имеет внутренний IP 192.168.31.3

    * МС — маршрутизатор-сервер в квартире 1, МК2 — маршрутизатор в квартире 2, МК3 — маршрутизатор в квартире 3
    * Конфигурации устройств опубликованы в спойлере в конце статьи.

    И так, пинги между узлами сети 192.168.31.0/24 ходят, пора перейти к настройке GRE-туннеля. Перед этим, дабы не терять доступ к маршрутизаторам, стоит настроить SSH-туннели для проброса 22 порта на VPS, таким образом, что, например, на 10022-ом порту VPS будет доступен маршрутизатор из квартиры 2, а на 11122-порту VPS будет доступен маршрутизатор из квартиры 3. Настройку проброса лучше всего выполнить все тем-же sshtunnel, так как он восстановит туннель в случае его падения.

    Туннель настроен, можно подключаться к SSH через проброшенный порт:

    ssh root@МОЙ_VPS -p 10022

    Далее следует отключить OpenVPN:

    /etc/init.d/openvpn stop

    Теперь настроим GRE-туннель на маршрутизаторе из квартиры 2:

    ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
    ip link set grelan0 up
    

    И добавим созданный интерфейс в мост:

    brctl addif br-lan grelan0
    

    Аналогичную процедуру выполним на маршрутизаторе-сервере:

    ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
    ip link set grelan0 up
    

    И, также, добавим созданный интерфейс в мост:

    brctl addif br-lan grelan0
    

    начиная с этого момента пинги начинают успешно ходить в новую сеть и я, с удовлетворением отправляюсь пить кофе. Затем, чтобы оценить, как работает сеть на другом конце провода, я пытаюсь подключиться по SSH к одному из компьютеров в квартире 2, но ssh-клиент «зависает», не предлагая ввести пароль. Пробую подключиться к этому компьютеру по telnet на 22 порт и вижу строку, из которой можно понять, что соединение устанавливается, SSH-сервер отвечает, просто по какой-то причине не предлагает мне войти.

    $ telnet 192.168.10.110 22
    SSH-2.0-OpenSSH_8.1
    

    Пытаюсь подключиться к нему же по VNC и вижу черный экран. Я убеждаю себя, что дело в удаленном компьютере, ведь к маршрутизатору из этой квартиры я спокойно могу подключиться по внутреннему адресу. Однако, я решаю подключиться к SSH этого компьютера через маршрутизатор и с удивлением обнаруживаю, что подключение удается, а удаленный компьютер работает вполне штатно, но при этом также не может подключиться к моему компьютеру.

    Я вывожу устройство grelan0 из моста и запускаю OpenVPN на маршрутизаторе в квартире 2 и убеждаюсь, что сеть вновь работает как положено и соединения не обрываются. Поиском натыкаюсь на форумы, где люди жалуются на такие же проблемы, где им советуют поднять MTU. Однако, повысить MTU для VPN первого уровня (wg0) мне не удалось: при MTU выше 1420, который выставляется автоматически, начинаются обрывы, но при этом, VPN второго уровня wg1, работающий поверх wg0, корректно работал с MTU 1600. Этого достаточно для установки MTU в 1500 для устройства gretap, для того чтобы этот интерфейс имел то же значение MTU, что и мост br-lan, в который планировалось добавить gretap. Насколько я понял, мост выставляет MTU равное меньшему из доступных значений на всех устройствах.

    Провел аналогичную настройку и на маршрутизаторе из квартиры 3, с той лишь разницей, что на маршрутизаторе сервере добавился второй интерфейс gretap с именем grelan1, который также был добавлен в мост br-lan.

    Все работает. Теперь можно поместить сборку gretap в автозагрузку. Для этого:

    Поместил эти строки в /etc/rc.local на маршрутизаторе в квартире 2:

    ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
    ip link set dev grelan0 mtu 1500
    ip link set grelan0 up
    brctl addif br-lan grelan0
    

    Добавил это в /etc/rc.local на маршрутизаторе в квартире 3:

    ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
    ip link set dev grelan0 mtu 1500
    ip link set grelan0 up
    brctl addif br-lan grelan0
    

    И на маршрутизаторе-сервере:

    ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
    ip link set dev grelan0 mtu 1500
    ip link set grelan0 up
    brctl addif br-lan grelan0
    
    ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
    ip link set dev grelan1 mtu 1500
    ip link set grelan1 up
    brctl addif br-lan grelan1
    

    После перезагрузки клиентских роутеров я обнаружил, что они по какой-то причине не подключаются к серверу. Подключившись к их SSH (благо, я предварительно настроил sshtunnel для этого) было обнаружено, что WireGuard зачем-то создает маршрут для endpoint, при этом неверный. Так, для 192.168.30.2 в таблице маршрутов был указан маршрут через интерфейс pppoe-wan, то есть через интернет, хотя маршрут до него должен был быть направлен через интерфейс wg0. После удаления этого маршрута соединение восстановилось. Найти где-то инструкций о том, как заставить WireGuard не создавать этих маршрутов мне не удалось. Более того, я даже не понял, особенность это OpenWRT, либо самого WireGuard. Не став долго разбираться с этой проблемой, я просто добавил на оба роутера в скрипт, зацикленный по таймеру, строку удалявшую этот маршрут:

    route del 192.168.30.2
    

    Подводя итоги


    Полного отказа от OpenVPN я пока не добился, так как мне нужно иногда подключаться к новой сети с ноутбука, либо телефона, а настройка gretap устройства на них в общем случае невозможна, но, несмотря на это, я получил преимущество в скорости передачи данных между квартирами и, например, использование VNC теперь не доставляет неудобств. Пинг уменьшился незначительно, но стал более стабильным:

    При использовании OpenVPN:

    [r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
    PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
    64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
    ...
    64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms
    
    --- 192.168.10.110 ping statistics ---
    20 packets transmitted, 20 received, 0% packet loss, time 19006ms
    rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms
    

    При использовании WireGuard:

    [r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
    PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
    64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
    ...
    64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
    --- 192.168.10.110 ping statistics ---
    20 packets transmitted, 20 received, 0% packet loss, time 19003ms
    rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms
    

    На него в большей степени влияет высокий пинг до VPS, который составляет примерно 61.5 мс

    Однако, скорость увеличилась значительно. Так, в квартире с маршрутизатором-сервером я имею скорость подключения к Интернету 30 мбит/сек, а в остальных квартирах по 5 мбит/сек. При этом, во время использования OpenVPN мне не удавалось достичь скорости передачи данных между сетями больше 3,8 мбит/сек по показаниями iperf, в то время как WireGuard «прокачал» ее до тех же 5 мбит/сек.

    Конфигурация WireGuard на VPS
    [Interface]
    Address = 192.168.30.1/24
    ListenPort = 51820
    PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

    [Peer]
    PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>
    AllowedIPs = 192.168.30.2/32

    [Peer]
    PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>
    AllowedIPs = 192.168.30.3/32

    [Peer]
    PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>
    AllowedIPs = 192.168.30.4/32


    Конфигурация WireGuard на МС (добавляется в /etc/config/network)
    #VPN первого уровня - клиент
    config interface 'wg0'
            option proto 'wireguard'
            list addresses '192.168.30.2/24'
            option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
            option auto '1'
    
    config wireguard_wg0
            option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
            option endpoint_port '51820'
            option route_allowed_ips '1'
            option persistent_keepalive '25'
            list allowed_ips '192.168.30.0/24'
            option endpoint_host 'IP_АДРЕС_VPS'
    
    #VPN второго уровня - сервер
    config interface 'wg1'
            option proto 'wireguard'
            option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
            option listen_port '51821'
            list addresses '192.168.31.1/24'
            option auto '1'
            option mtu '1600'
    
    config wireguard_wg1
            option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
            list allowed_ips '192.168.31.2'
    
    config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
            option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
            list allowed_ips '192.168.31.3'
    


    Конфигурация WireGuard на МК2 (добавляется в /etc/config/network)
    #VPN первого уровня - клиент
    config interface 'wg0'
            option proto 'wireguard'
            list addresses '192.168.30.3/24'
            option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
            option auto '1'
    
    config wireguard_wg0
            option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
            option endpoint_port '51820'
            option persistent_keepalive '25'
            list allowed_ips '192.168.30.0/24'
            option endpoint_host 'IP_АДРЕС_VPS'
    
    #VPN второго уровня - клиент
    config interface 'wg1'
            option proto 'wireguard'
            option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
            list addresses '192.168.31.2/24'
            option auto '1'
            option listen_port '51821'
            option mtu '1600'
    
    config wireguard_wg1
            option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
            option endpoint_host '192.168.30.2'
            option endpoint_port '51821'
            option persistent_keepalive '25'
            list allowed_ips '192.168.31.0/24'
    


    Конфигурация WireGuard на МК3 (добавляется в /etc/config/network)
    #VPN первого уровня - клиент
    config interface 'wg0'
            option proto 'wireguard'
            list addresses '192.168.30.4/24'
            option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
            option auto '1'
    
    config wireguard_wg0
            option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
            option endpoint_port '51820'
            option persistent_keepalive '25'
            list allowed_ips '192.168.30.0/24'
            option endpoint_host 'IP_АДРЕС_VPS'
    
    #VPN второго уровня - клиент
    config interface 'wg1'
            option proto 'wireguard'
            option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
            list addresses '192.168.31.3/24'
            option auto '1'
            option listen_port '51821'
            option mtu '1600'
    
    config wireguard_wg1
            option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
            option endpoint_host '192.168.30.2'
            option endpoint_port '51821'
            option persistent_keepalive '25'
            list allowed_ips '192.168.31.0/24'
    


    В описанных конфигурациях для VPN второго уровня я указываю клиентам WireGuard порт 51821. По идее это не нужно, так как клиент установит соединение с любого свободного непривилегированного порта, но я сделал так, чтобы можно было запретить все входящие соединения на интерфейсах wg0 всех маршрутизаторов, кроме входящих UDP-соединений на порт 51821.

    Надеюсь, что статья будет кому-то полезна.

    P.S. Также, хочу поделиться своим скриптом, который шлет мне PUSH-уведомление на телефон в приложение WirePusher, когда в моей сети появляется новое устройство. Вот ссылка на скрипт: github.com/r0ck3r/device_discover.

    UPDATE: Конфигурация OpenVPN-сервера и клиентов

    OpenVPN-сервер
    client-to-client
    
    ca /etc/openvpn/server/ca.crt
    cert /etc/openvpn/server/vpn-server.crt
    dh /etc/openvpn/server/dh.pem
    key /etc/openvpn/server/vpn-server.key
    
    dev tap
    ifconfig-pool-persist /etc/openvpn/ipp.txt 0
    keepalive 10 60
    proto tcp4
    server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
    status /var/log/openvpn-status.log
    verb 3
    comp-lzo


    OpenVPN-клиент
    client
    tls-client
    dev tap
    proto tcp
    remote VPS_IP 1194 # Change to your router's External IP
    resolv-retry infinite
    nobind
    
    ca client/ca.crt
    cert client/client.crt
    key client/client.key
    dh client/dh.pem
    
    comp-lzo
    persist-tun
    persist-key
    verb 3



    Для генерации сертификатов использовал easy-rsa

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 26

      +1

      Если вы не доверяете vps, то зачем вы шифруете трафик до него? Сделайте тупой gre или vxlan с plaintext трафиком, внутри которого уже гоняйте нормальный шифрованный трафик. И быстрее, и отлаживать проще (видно вложенный шифрованный трафик в tcpdump).


      Использование же sshtunnel чревато tcp головного udp, это очень плохой антипаттерн для трафика.

        0
        я так понимаю, что для организации gre нужен выделенный IP с обеих сторон, но у меня этого нет — именно поэтому и было принято подобное решение. А vxlan я даже не рассматривал. Почитаю о нем.
          0

          vxlan даст вам udp транспорт (без шифрования). Но там надо иметь endpoint'ы с обоих сторон.


          Если вам очень нужно иметь tcp-туннель, то можно сделать tcp без шифрования. Кстати, тот же ssh умеет использовать jump hosts, так что можно наколхозить сеть на одном ssh.

        0
        Поделитесь пожалуйста, чем ещё на практике Wireguard лучше OpenVPN?
        (кроме повышения скорости, хотя тут мне кажется именно различие конфигурации и привело к этому)
        Тоже присматриваюсь к Wireguard, но пока что старый добрый OpenVPN у меня по-прежнему в строю. Почитал предыдущие статьи, как понимаю это пока что только в последних ядрах линукса можно получить такие скорости (потому что там Wireguard впаян в ядро), а с телефонами картинка мрачная…
          0
          Ну его главными преимуществами всегда называют высокую скорость и простоту конфигурации. Также он меньше нагружает и без того слабый процессор маршрутизатора, в том числе по той причине, что он реализован в виде модуля ядра
            +1
            разница в скорости у них не какая-то на уровне погрешности, а огромная.
            3 года назад на wireguard объединял хосты в разных ДЦ у DigitalOcean в одну сеть, ну и затестил опенвпн и ваергуард, ну так голый канал выдавал 1,7Гб/с, задержки 1-2 мс, в опенвпн — 103 Мб/с, и 7мс, wireguard стабильно держал 600Мб/с и 3 мс (правда первый пакет идёт 7мс). т.к. хост в другом дц нужен был как удалённая реплика для монги, вопрос с выбором сам отпал. За 2 года как я там работал — проблем ниразу не возникло.
              +1
              Почитал предыдущие статьи, как понимаю это пока что только в последних ядрах линукса можно получить такие скорости (потому что там Wireguard впаян в ядро),
              То, что он не был принят в ядро, означало лишь то, что при сборке ядра нужно было накладывать патчи. Наоборот, принятие WG в ядро может привести к некоторой просадке производительности, потому что одним из условий принятия было «мы принимаем вашу криптографию, без которой WG работать не может, в ядро, но в некоторых моментах в качестве ответного жеста вы обязуетесь использовать то, что уже есть в ядре, пусть оно и медленнее, чем ваше». Впрочем, это всё равно быстрее, чем OpenVPN, который работает в юзерспейсе. Конечно, ещё есть IPSec, но WG выигрывает у него простотой настройки.

              а с телефонами картинка мрачная
              Наличие WG в ядре не гарантирует, что производитель вашего телефона не отключил WG на этапе сборки ядра, поэтому кастомные ядра — наше всё.
                +1

                Помимо того, о чём уже написали выше, Wireguard поддерживает роуминг клиента. К примеру, вы с телефона подключены через SSH/RDP по мобильной сети к какому-либо серверу, переключаетесь на Wi-Fi, но соединение остаётся активным и не прерывается. Лично для меня, это самый огромный плюс, так как больше никто так не умеет, а пользуюсь я этим достаточно часто.

                  0

                  Можете мое сообщение всерьез не рассматривать — но ровно так у меня себя ведет Cisco VPN client (anyconnect который)

                    0

                    Не буду спорить, возможно там и есть такой функционал, но за полчаса поисков я не смог ничего найти про плавное переключение между разными сетями без разрыва соединения между сервером и клиентом VPN.
                    В любом случае, Wireguard пока не конкурент Cisco. Должно пройти достаточно много времени, прежде чем новому типу VPN начнут доверять компании.

                0
                Не могли бы вы к статье приложить OpenVPN конфигурацию? Хотелось бы на нее тоже взглянуть
                  0
                  приложил
                    +1
                    Спасибо. Я просто думал можно ли как-то уровнять условия с Wireguard, чтобы более объективно сравнить задержку и скорость. Навскидку, в конфиге не хватает tcp-nodelay, который может сильно повлиять, и comp-lzo компрессию надо бы убрать, она грузит цпу, а толку от нее мало, бывает даже больше вреда. Ну и udp все-таки быстрее будет, но в вашем случае это не поменять (хотя, провайдер 53 порт тоже режет? не должен). Интересно как изменилась бы задержка с такими настройками.
                      0
                      Попробовал включить tcp-nodelay и выключить компрессию — скорость возросла незначительно до ~4 мбит/сек, но пинг, как мне показалось, стал еще более нестабильным, хотя нужно попробовать потестировать еще, так как может канал был более загруженным. Я сообщу Вам, когда проведу более масштабное тестирование с этими настройками.

                      Ну и udp все-таки быстрее будет, но в вашем случае это не поменять (хотя, провайдер 53 порт тоже режет? не должен)

                      провайдер режет только входящие соединения и только от своих же сетей. Я попробовал воспользоваться STUN-клиентом для открытия UDP-порта 51820, затем поднял на этом порту netcat и попытался подключиться по полученному от STUN-сервера адресу со своего VPS. Соединение успешно установилось, данные пошли. Но при попытке соединения с узлов в квартире 2 и квартире 3, которые являются клиентами того же провайдера, что и я, я получал ошибку «Connection refused».
                        0
                        Спасибо за пояснение. Буду ждать результата тестов)
                          0
                          Протестировал.
                          С отключенной компрессией и отключенным tcp-nodelay:
                          rtt min/avg/max/mdev = 124.963/143.488/249.760/38.576 ms
                          


                          С отключенной компрессией и включенным tcp-nodelay
                          rtt min/avg/max/mdev = 124.819/137.237/174.284/17.251 ms
                          


                          В обоих случаях скорость по показаниям iperf держится в районе 3.5 — 4.7 мбит/сек, в зависимости от размера tcp-window

                          При этом WireGuard дает такие цифры:
                          rtt min/avg/max/mdev = 124.889/127.775/153.315/7.608 ms
                          

                          и при этом скорость находится в районе 5 мбит, иногда даже чуточку выше, практически независимо от размера tcp window. В общем выдает те же значения, что и какой-нибудь условный speedtest
                            0
                            Спасибо!
                  0

                  EoIP+IPSec не рассматривали как альтернативу?

                    0
                    Нет., не рассматривал, так как с самого начала настроил OpenVPN и он просто работал. На WireGuard перешел, из-за того, что меня привлекла его простота
                    0

                    Tinc VPN умеет в L2 и mesh. (Но по скорости он как OpenVPN т.к. тоже не в ядре)

                      0

                      У меня между домашними сетями tun. При 100мбитах, в среднем, скорость между сетями 20-30мбит. К сожалению пластиковый роутер не в состоянии справляться с шифрованием быстрее + openssl на openwrt весьма отличается от "взрослого" openssl. Я пробовал wireguard год назад, и получил прирост 3-5мбит, что в моем понимании не серьезно.
                      Для себя сделал вывод что wireguard штука хорошая, но видимо на пластиковых роутерах особых плюсов перед openvpn я не получу.

                        0
                        Совсем не реклама, используйте кинетик, у меня дает 50-55 Мбит на wireguard.
                        0

                        А как же статьи с Wireguard, Shadowsocks и v2ray?
                        И маскировкой за Cloudflare

                          0
                          не совсем понял, что имеется ввиду
                          0
                          А можете подсказать что-то по вопросу qna.habr.com/q/709981?e=8556477?
                            0
                            Думаю, что Вам поможет следующее:
                            На компьютере с интерфейсом 192.168.0.1
                            #включим IP forwarding, если он не включен
                            echo 1 > /proc/sys/net/ipv4/ip_forward
                            iptables -t nat -A POSTROUTING -o ИМЯ_ИНТЕРФЕЙС_С_192.168.0.1 -j MASQUERADE
                            


                            На компьютерах из сети 10.x.x.x
                            route add -net 192.168.0.0/24 gw 10.0.0.2
                            

                          Only users with full accounts can post comments. Log in, please.