Метка: openvpn

  • OpenVPN поверх PPPOE ( openvpn over pppoe redirect-gateway def1 )

    Существует проблема замены маршрута по умолчанию при использовании openvpn поверх pppoe
    дело в том, что pppoe поднимается с неправильным маршрутом по умолчанию, выглядит он вот так

    Таблица маршутизации ядра протокола IP
    Destination Gateway Genmask Flags Metric Ref Use Iface
    0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0

    опенвпну не нравится gateway поэтому его нужно исправить, например на вот такой

    Таблица маршутизации ядра протокола IP
    Destination Gateway Genmask Flags Metric Ref Use Iface
    0.0.0.0         222.222.222.22  0.0.0.0         UG    0      0        0 ppp0

    для этого создадим файл

    /etc/ppp/ip-up.d/default-gateway

    не забываем задать ему chmod u+x
    с таким содержимым

    #!/bin/bash
    
    if [ $(ip route list exact default |\
      awk '/^default/ {print $2}') = dev ];
    then
             IF=$(ip route | awk '/^default/ {print $3}')
             GW=$(ip address show $IF |\
      awk '/peer/ {print $4}' | cut -d"/" -f1)
             ip route replace default via $GW dev $IF
    fi

    если руками выполнить этот скрипт то он предложит сделать примерно вот такое

    ip route replace default via 222.222.222.22 dev ppp0

    После чего опенвпн успешно подменит маршрут на свой, и трафик полетит в нужную сторону.

    если до какого-то хоста нам нужно пустить трафик вне ОпенВПна, например до своего хоста, для подключения по ssh, то в этот же файл добавляем

    #my route 91.91.91.91
    route add 91.91.91.91 gw 222.222.222.22 dev ppp0

    если шлюз динамический, то используем $GW вместо 222.ххх

  • linux два интерфейса (linux два провайдера)

    Как и обещал, пишу.
    Довольно много времени потратил на понимание происходящего..

    И так есть у меня сервер, он же ОпенВПН сервер в одной организации. и вот упёрлась организация в ширину канала, собственно беда в том, что по этому же каналу ходил SIP трафик, и сильно «лагал» когда ширины канала не хватало 🙁

    Подключаем ещё один канал от второго провайдера. есть сервер в нём внешний канал (eth1), локальная сеть(eth0), ещё ходит OpenVPN (tun0) для связи с остальными филиалами.

    Добавился ещё один внешний провайдер (eth4). для его подключение я сделал так.
    Напомню, что linux умеет работать с несколькими таблицами маршрутизации

    Тоесть для удобства я могу для каждого своего филиала создать табилцу маршрутизации, и в ней уже удобно управлять маршрутами, потом мне не надо будет листать простыню маршрутов таблицы main

    в файл

     /etc/iproute2/rt_tablesCode language: Bash (bash)

    Добавил 2 таблицы

    201 T1
    202 T2Code language: Bash (bash)

    У каждого провайдера будет своя таблица маршрутизация
    Т1 — первый провайдер
    Т2 — второй

    Создал скрипт, что будет заведовать маршрутизацией.

    #!/bin/sh
    IP1=217.111.111.99
    IP2=94.11.111.81
    P1=217.111.111.97
    P2=94.11.111.82
    IF1=eth1
    IF2=eth4
    # добавим дефаулт гетвей в каждую таблицу.
    ip route add default via $P1 table T1
    ip route add default via $P2 table T2
    # Говорим, что по дефолту будем ходить через первого провайдера.
    ip route add default via $P1
    ip rule add from $IP1 table T1
    ip rule add from $IP2 table T2
    #Перечисляю хосты, что будут ходить через новый интерфейс вот так
    #Но не забываем их указывать в NAT iptables
    ip rule add from 192.168.5.107 table T2
    ip rule add from 192.168.5.108 table T2
    ip rule add from 192.168.5.112 table T2
    ip rule add from 192.168.5.199 table T2
    #Это так на всякий случай
    echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
    echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
    echo 0 > /proc/sys/net/ipv4/conf/all/send_redirectsCode language: Bash (bash)

    Где
    IP# это ИП адрес на интерфейсе,
    P# шлюз на интерфейсе
    после этого сервер отвечает по обоим интерфейсам. также пинги/трацерты с сервера ходят через нужный интерфейс.

     ping -I eth4 ya.ru Code language: Bash (bash)

    теперь мне нужно что нужные мне клиенты ходили через этот интерфейс наружу. в iptables.up.rules у меня есть правила НАТа

    -A POSTROUTING -s 192.168.5.102 -o eth4 -j MASQUERADE
    -A POSTROUTING -s 10.10.10.6 -o eth4 -j MASQUERADE
    -A POSTROUTING -s 192.168.0.0/255.255.0.0 -o eth1 -j MASQUERADE
    -A POSTROUTING -s 10.10.0.0/255.255.0.0 -o eth1 -j MASQUERADECode language: Bash (bash)

    первыми 2мя строками я хочу чтоб вот 192.168.5.102 и 10.10.10.6 НАТились через нового провайдера. rp_filter выключаем вот так в sysctrl

    net.ipv4.conf.default.rp_filter = 0
    net.ipv4.conf.all.rp_filter = 0Code language: Bash (bash)

    Теперь, надо понимать, что если идёт пакет на 192.168.5.108, то он попадает в таблицу T2 а в ней у нас что? правильно один только дефаултгетвей! а что такое другие подсети филиалов и ОпенВПН мы знать не знаем, поэтому тоже необходимо добавить маршрут в таблицу Т2 для указания где у нас ходятся 10.10.10.0

    ip route add 10.10.10.0/24 via 10.10.10.2 dev tun0 table T2Code language: Bash (bash)

    Всё это кидаем в первый скрипт, а скрипт в автозагрузку. Теперь ещё важный момент, браузер у нас работает прозрачно через squid3 и получается, что весь трафик ходит через один интерфейс, а хттп трафик ходит через другой, не хорошо получается. поэтому читаем вот эту статью

  • OpenVPN Windows клиент (настройка openvpn windows)

    Недавно я писал, как поднять OpenVPN server на днях мне понадобилось присоединить к этой сети Ноутбук, который поедет в другие города и страны.

    Качаем дистрибутив OpenVPN

    http://openvpn.net/index.php/open-source/downloads.html

    OpenVPN GUI Идёт в комплекте.

    На сервере генерируем ключи

    cd  /usr/share/doc/openvpn/examples/easy-rsa/2.0
    source ./vars
    ./build-key noutCode language: Bash (bash)

    Копируем файлы на ноутбук из /etc/openvpn/keys/

    Нам нужны ca.crt nout.key и nout.crt

    У себя я положил их в C:\keys\

    Теперь создаём файл конфигурации клиента.

    C:\Program Files\OpenVPN\config\client.ovpnCode language: Bash (bash)

    Обратим внимание, что в Windows файлы конфигурации имеют вот такое расширение.

    remote 111.111.111.111 1194
    client
    dev tun
    proto udp
    resolv-retry infinite # this is necessary for DynDNS
    nobind
    user nobody
    group nogroup
    persist-key
    persist-tun
    ca c:\\keys\\ca.crt
    cert c:\\keys\\nout.crt
    key c:\\keys\\nout.key
    #ca ca.crt
    #cert nout.crt
    #key nout.key
    comp-lzo
    verb 4
    mute 20
    #redirect-gateway
    #show-net-up
    verb 4Code language: Bash (bash)

    На сервере создаём конфиг для этого клиента

    /etc/openvpn/ccd/noutCode language: Bash (bash)
    # роутинг на сеть Первого офиса
    push "route 192.168.1.0 255.255.255.0"
    # роутинг на сеть Управы офиса
    push "route 192.168.5.0 255.255.255.0"Code language: Bash (bash)

    Теперь наш клиент будет видеть вот эти 2 подсети.
    OpenVPN GUI

    Вот так подключаемся, и радуемся жизни 🙂
    Нам выдастся адрес из подсети 10.10.10.1 и мы сможем пользоваться внутренними ресурсами

    У нас есть доступ в компаративную сеть из любой точки мира!

  • Ubuntu OpenVPN Server (Настройка, соединение филиалов сеть)

    Изначально эту статью я писал для Хабра, но чуть позже решил продублировать в Блог.

    Не так давно передо мною встала задача соединить в единую сеть филиалы одной крупкой компании, разбросанные по Сибири. Главная проблема была в том, что OpenVPN надо было заставить работать поверх нестабильного PPPoE попутно пустив весь трафик через OpenVPN

    Первоначальная цель была в экономии денег на Интернет трафике в филиалах т.к. в удалённых районах цена безлимитного ADSL с шириной в 256кб/с стоила порядка 7-10т.р. в месяц, а интернет был жизненно необходим.
    Вся радость была в том, что почти все филиалы имели подключения одного провайдера, в котором существовало понятие локального и пирингово трафика, а в Главном офисе был выделенный широкий Интернет (другой провайдер, но волей случая он был лоялен к провайдеру филиалов и у него был «пиринговый трафик» с ценой около 6 копеек за мегабайт).

    1. proxy

    Самое быстрое решение это было обычный каскад proxy серверов, так и было сделано т.к. раньше все филиалы раздавали интернет у себя прямо модемом, то нужно было всем выделить по 1 системнику, который бы выполнял роль шлюза, системники были не подарки, кто даст 800й пень, кто 233, в общем у кого что было.. Хотя сегодня за 4-7 т.р. можно собрать достойный шлюз, но хозяин-барин, хочу говорит без затрат!

    На эти шлюзы была установлена ubuntu 8.04 LTS настроена в виде шлюза, чтоб воткнул в локальную сеть, в модем и в розетку, и сразу всё работало т.к. во многих филиалах, админы могли только нажать «Any key» на клавиатуре пользователя, но не беда, дело шло, постепенно 7 филиалов перенастроило свои модемы, и воткнули шлюзы 🙂

    сразу же поднимали прокси каскадом, заруливали туда http трафик, но как мы все знаем, хттп трафик это всего некий % от общего трафика, перейдя на более простые тарифы, экономия была, но условная, ведь нерадивый админ или пользователь мог например через torrent стянуть что-то весомое, что сулило попаданием на деньги филиалу…

    Попутно появлялись другие задачи в центральном офисе — перенос компаративного почтаря, шлюза, портала настроенного году в 2002 и не тронутого с тех пор, но это заслуживает отдельной статьи…
    А нас пока интересует просто сеть…

    2. OpenVPN

    Эту штуку я видел в первый раз, был некий страх перед первым знакомством, далее чтение мануалов и интернетов, закатав рукава я полез ставить 🙂

    2.1 Сервер
    имеет 2 сетевых адаптера eth1 (192.168.5.x) — Локальная сеть и eth0 (real ip 111.111.111.111) Интернет с широким каналом.

    apt-get install openvpnCode language: Bash (bash)

    Далее создаём файл конфигурации сервера

    touch /etc/openvpn/server.confCode language: Bash (bash)

    при загрузке системы автоматически поднимаются все VPN соединения, для которых в папке /etc/openvpn есть соответствующие файлы с расширением .conf

    у меня он получился примерно таким.

    port 1194 #Порт
    proto udp #Протокол
    dev tun   #Название виртуального устройства  
    ca /etc/openvpn/ca.crt
    cert /etc/openvpn/server.crt
    key /etc/openvpn/server.key # This file should be kept secret
    dh /etc/openvpn/dh1024.pem
    server 10.10.10.0 255.255.255.0 # vpn subnet
    ifconfig-pool-persist ipp.txt # Тут будут храниться ip адреса клиентов
    push "route 192.168.5.0 255.255.255.0" # home 
    keepalive 10 120
    comp-lzo
    user nobody
    group nogroup
    persist-key
    persist-tun
    status openvpn-status.log
    log-append  openvpn.log
    verb 4
    mute 20
    client-to-client
    client-config-dir /etc/openvpn/ccd # Тут будут настройки для каждого филиала
    route 192.168.0.0 255.255.255.0 # Маршрут от сервера до филиала 1
    route 192.168.1.0 255.255.255.0 # Маршрут от сервера до филиала 2Code language: Bash (bash)

    Создаём каталог, в котором будут хранится индивидуальные настройки клиентов:

    mkdir /etc/openvpn/ccdCode language: Bash (bash)

    Теперь необходимо создать ключи и сертификаты для шифрования и авторизации

    cd  /usr/share/doc/openvpn/examples/easy-rsa/2.0
    source ./vars
    ./clean-all
    ./build-caCode language: Bash (bash)

    UPD1
    если у вас получается как-то так

    # source ./vars
    **************************************************************
      No /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf file could be found
      Further invocations will fail
    **************************************************************
    NOTE: If you run ./clean-all, I will be doing a rm -rf on /usr/share/doc/openvpn/examples/easy-rsa/2.0/keysCode language: Bash (bash)

    или вот так

    # ./build-ca
    grep: /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf: Нет такого файла или каталога
    pkitool: KEY_CONFIG (set by the ./vars script) is pointing to the wrong
    version of openssl.cnf: /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf
    The correct version should have a comment that says: easy-rsa version 2.xCode language: Bash (bash)

    то скорее всего нет файла openssl.cnf я вышел из ситуации примерно так

    cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl-1.0.0.cnf /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnfCode language: Bash (bash)

    и тут снова продолжаем на том моменте где был косяк.

    Теперь создадим сертификат и приватный ключ для сервера:

    ./build-key-server serverCode language: Bash (bash)

    Создаём ключ для клиента (если клиентов несколько, процедуру придётся повторить):

    ./build-key client1Code language: Bash (bash)

    для каждого клиента должно быть указано своё уникальное имя (в данном случае client1).
    Процедура подключения Win клиентов описана тут

    если новый клиент создаётся спустя некоторое время, процедура будет выглядеть следующим образом:

    cd  /usr/share/doc/openvpn/examples/easy-rsa/2.0
    source ./vars
    ./build-key client2Code language: Bash (bash)

    Генерируем параметры Диффи-Хеллмана:

    ./build-dhCode language: Bash (bash)

    Помещаем следующие файлы в директорию /etc/openvpn/

        * ca.crt
        * server.crt
        * dh1024.pem
        * server.key Code language: Bash (bash)

    Создаём файл /etc/openvpn/ipp.txt

    Конфигурационный файл клиентской машины /etc/openvpn/client.conf у меня получился примерно таким

    remote 111.111.111.111 1194
    client
    dev tun
    proto udp
    resolv-retry infinite # this is necessary for DynDNS
    nobind
    user nobody
    group nogroup
    persist-key
    persist-tun
    ca /etc/openvpn/ca.crt
    cert /etc/openvpn/client1.crt
    key /etc/openvpn/client1.key
    comp-lzo
    verb 4
    mute 20
    redirect-gateway
    #show-net-up
    verb 4Code language: Bash (bash)

    Теперь необходимо скопировать с сервера в папку /etc/openvpn/ сгенерированные клиентские ключи и авторитарный сертификат сервера:

        * ca.crt
        * client1.crt
        * client1.key Code language: Bash (bash)

    Если за клиентом скрывается сеть 192.168.1.х то, чтоб сервер видел её нужно добавить на сервер маршрут до неё.

    На сервере создаём файл /etc/openvpn/ccd/client1 такого содержания:

    iroute 192.168.1.0 255.255.255.0
    # роутинг на сеть филиала2, чтоб 2 филиала знали друг друга
    #push "route 192.168.100.0 255.255.255.0"
    #Заворачиваем весь трафик в OpenVPN
    push "redirect-gateway def1"Code language: Bash (bash)

    Вот тут собственно и случилась самая злая проблема у меня.

    OpenVPN получив директиву

    push "redirect-gateway def1"Code language: Bash (bash)

    (при наличии ‘pull’ в своей конфигурации), клиент не удаляет старый маршрут, а добавляет в таблицу маршрутизации записи вида:

     0.0.0.0/1 via 192.168.231.5 dev tun0  
     128.0.0.0/1 via 192.168.231.5 dev tun0Code language: Bash (bash)

    и если openvpn идёт по ethernet то всё работает и радует админа и пользователей, но великий ppp любит поднимать вот такой маршрут.

    0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0 Code language: Bash (bash)

    И вот OpenVPN ругается примерно вот так

    Jul  2 19:28:53 ino ovpn-client[14465]: NOTE: unable to redirect default gateway -- Cannot read current default gateway from system  Code language: Bash (bash)

    Решение этой проблемы искалось долго и нудно, хотя оно на поверхности. если в этом «кривом» маршруте ppp указывать шлюз вместо 0.0.0.0 реальный шлюз, то ОpenVPN видит этот маршрут и добавляет свой без проблем.

    Поэтому я создал файл

    /etc/ppp/ip-up.d/routingCode language: Bash (bash)

    В который прописал небольшой скрипт. (прошу ногами не пинать, я очень ленивый, и полноценный скрипт определения шлюза и правки маршрутов писать не стал, а сделал как простой костыль)
    Буду очень рад, если кто-то предложит более логичный, надёжный, и универсальный метод правки маршрутов на лету.
    Пока ещё нет уверенности, что всё будет на 100% работать при обрывах ppp, Но жизнь покажет, если что — поправлю топик.

    #! /bin/sh 
    
    #Определяем выданный шлюз по умолчанию у меня он всегда  разный но в сети 222.х.х.х
    gw1=`ip route show | grep 222 | awk '{print $1}'` 
    # Удаляем 0.0.0.0 0.0.0.0 
    route del default 
    # Добавляем маршрут с верным шлюзом 
    route add -net default gw ${gw1} dev ppp0Code language: Bash (bash)

    Делаем его исполняемым

    chmod ug+x /etc/ppp/ip-up.d/routingCode language: Bash (bash)

    После чего ребут, спустя некоторое время сервер перестал пинговаться по внешнему ипу, но стал отзываться по внутреннему — 10.10.10.26

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

    -A POSTROUTING -s 192.168.0.0/255.255.0.0 -j MASQUERADECode language: Bash (bash)

    Тут не указана привязка ни к внешнему интерфейсу, ни ip 🙂
    когда по разным причинам у нас не будет openvpn то у пользователей будет прямой инет, а когда он появится, то весь трафик полетит через него.

    Заключение

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

    push "redirect-gateway def1"Code language: Bash (bash)

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

    Ах да, чуть не забыл, о самом главном — profit

    Помимо того, что теперь вся сеть обращается к серверам и сервисам филиалов и центра по внутренним ip адресам, так ещё и финансовая экономия.

    Раньше каждый филиал тратил на интернет в среднем по 7 000р. в месяц, сейчас в месяц каждый из них платит по 550р. за доступ к пирингу, интернет не расходуется (кроме центрального), для начала было запущено 7 филиалов, дальше будет больше.
    получается, что за год при старой схеме компания тратила бы на интернет 588 000р., а при текущей схеме в год будет потрачено 46 200р.

    Что дальше?

    А теперь, на этой всей хе…. мы попробуем взлететь! я попробую развернуть IP Телефонию, чтоб минимизировать расходы на Телефонные междугородние переговоры между филиалами, связать софтАТС с аппаратными в филиалах, о чём обязательно напишу. Удачи

    update1 Много вопросов возникло к термину «Крупная компания» попробую прояснить.

    Крупная она в Сибири, центр имеет штат 200 сотрудников, филиалы от 20 до 60, к каждому филиалу ещё крепятся 10-20 объектов. по 5-15 человек. филиалов менее 30ти.

    Компания крайне не поворотлива, основной контроль идёт от государства, оборудование, компания делает некие шаги в сторону ИТ развития 🙂

    Update2
    И так, после тестирования выявилось, что если надолго опустить сервер управы, то клиенты не охотно поднимают openvpn и трафик может пойти прямо в дорогой инет.
    Также если принудительно рвётся ADSL канал, то опенвпн вроде и пытается стартануть заново, но что-то у него это не получается, так и ходит по кругу.
    пробовал всякие опции и keepalive и ping-restart и прочее… не помогало…

    Поэтому пишем небольшой скрипт, который будет проверять состояние дел.

    touch /usr/bin/vpn_keepalive.shCode language: Bash (bash)

    C содержанием.

    #! /bin/sh
    
    # Нужна ли нам отладка, рас комментировать нужное
    #debug_out=/dev/null
    debug_out=/dev/stdout
    #NEXTHOP Это хост внутри ВПН сети
    # я взял внутренний ип OpenVPN сервера
    NEXTHOP=192.168.5.1
    # Комманда перезапуска Опенвпн
    OPEN_VPN_CMD="sudo /etc/init.d/openvpn restart"
    PING=/bin/ping
    
    logger_opts="-t $0"
    if [ "$debug_out" = "/dev/stdout" ]
    then
            logger_opts="$logger_opts -s"
    fi
    pckts_rcvd=`$PING -c 8 -q -W 2 $NEXTHOP | grep transm | awk '{print $4}'`
    echo "host: $NEXTHOP, pckts_rcvd: $pckts_rcvd" >$debug_out
    if [ $pckts_rcvd -eq 0 ]
    then
        echo "Connection with $NEXTHOP lost, resetting" | logger $logopts
        $OPEN_VPN_CMD > $debug_out
    else
        echo "Connection with $NEXTHOP up, no action" | logger $logopts
    fiCode language: Bash (bash)

    Делаем его исполняемым

    chmod ug+x /usr/bin/vpn_keepalive.shCode language: Bash (bash)

    Скрипт пингует хост, и если 0 пакетов вернулось, то выполнит команду рестарта.
    после чего всё гарантированно поднимается, вливаются верные маршруты, и трафик идёт через ВПН трафик

    Кидаем этот скрипт в крон

    crontab -eCode language: Bash (bash)

    например каждые 2 минуты.

    0-59/2 * * * * /usr/bin/vpn_keepalive.shCode language: Bash (bash)

    И всё если дебаг включен, то в логах (syslog) будет отмечено вот так.

    logger: Connection with 192.168.5.1 up, no actionCode language: Bash (bash)

    Удачи!

  • Проблема с MTU PPPoE

    И так, при соединении нескольких сетей, возникла проблема, что пинги не ходили, а сделано всё верно. Собака была зарыта вот тут

    /proc/sys/net/ipv4/ip_no_pmtu_discCode language: Bash (bash)

    Одним простым движением

    echo "1" > /proc/sys/net/ipv4/ip_no_pmtu_discCode language: Bash (bash)

    Всё решилось, но и для справки
    Цитата с ОпенНЕТа

    Переменная ip_no_pmtu_disc запрещает поиск PMTU (от англ. Path Maximum
    Transfer Unit Максимальный Размер Пакета для выбранного Пути). Для
    большинства случаев лучше установить в эту переменную значение FALSE,
    или 0 (т.е. система будет пытаться определить максимальный размер
    пакета, при котором не потребуется выполнять их фрагментацию, для
    передачи на заданный хост). Но иногда, в отдельных случаях, такое
    поведение системы может приводить к срывам соединений. Если у вас
    возникают такие проблемы, то вам следует попробовать отключить эту опцию
    (т.е. записать в переменную число 1) и установить нужное значение MTU.
    Хочу обратить ваше внимание на то, что MTU и PMTU это не одно и то же!
    MTU (от англ. Maximum Transfer Unit максимальный размер пакета)
    определяет максимальный размер пакета для наших сетевых интерфейсов, но
    не для сетевых интерфейсов на другом конце. PMTU опция, которая
    заставляет систему вычислять максимальный размер пакета, при котором не
    потребуется фрагментация пакетов, для маршрута к заданному хосту,
    включая все промежуточные переходы. Значение по-умолчанию FALSE (0),
    т.е. функция определения разрешена. Если записать число 1 в эту
    переменную, то функция определения PMTU будет запрещена. Переменная
    ip_no_pmtu_disc может принимать значение 0 или 1.

    ещё для эта проблема должна решаться вот так.

    iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags RST,SYN SYN -j TCPMSS --clamp-mss-to-pmtuCode language: Bash (bash)

    либо вот так

     iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128Code language: Bash (bash)