OpenVPN + Quagga OSPF нет маршрута при изменении MTU



  • 2 сервера подключены между собой по OpenVPN как сервер-клиент.
    Туннельная сеть 192.168.220.8/30

    Локальные сети серверов, которые транслируются в OSPF имеют адресацию 192.168.1.0/24 и 192.168.50.0/24

    Проблема такая, опишу пунктами

    1. поднимаем OpenVPN, и для теста прописываем роуты Local/Remote Network. Всё работает!
    2. роуты удаляем, поднимаем Quagga OSPF и прописываем туда сети. Появляется проблема - не ходят пакеты более 1472байт. ФРагментация не работает.
    3. прописываем tun-mtu 2100 - начинают ходить пакеты до 2072 байт включительно. Фрагментации так же нет.

    Мне этого мало, и я хочу чтобы пакеты фрагментировались. Чтобы я не пробовал прописывать в настройках в OpenVPN - оно не делает фрагментацию пакетов.
    И тут я замечаю одну малозаметную особенность:

    $ ping -c 3 -s 2300 -S 192.168.220.9 192.168.220.10
    PING 192.168.220.10 (192.168.220.10) from 192.168.220.9: 2300 data bytes
    2308 bytes from 192.168.220.10: icmp_seq=0 ttl=64 time=17.865 ms
    2308 bytes from 192.168.220.10: icmp_seq=1 ttl=64 time=18.887 ms
    2308 bytes from 192.168.220.10: icmp_seq=2 ttl=64 time=19.001 ms

    –- 192.168.220.10 ping statistics ---
    3 packets transmitted, 3 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 17.865/18.584/19.001/0.511 ms

    т.е. в рамках туннеля пакет в 2300 работает

    Дальше делаем пинг в удалённую локалку:

    $ ping -c 3 -s 2300 -S 192.168.50.1 192.168.1.10
    PING 192.168.1.10 (192.168.1.10) from 192.168.50.1: 2300 data bytes
    36 bytes from 192.168.220.9: Destination Host Unreachable
    Vr HL TOS  Len  ID Flg  off TTL Pro  cks      Src      Dst
    4  5  00 0834 4ee7  0 0000  40  01 4f86 192.168.50.1  192.168.1.10

    36 bytes from 192.168.220.9: Destination Host Unreachable
    Vr HL TOS  Len  ID Flg  off TTL Pro  cks      Src      Dst
    4  5  00 0834 6b6a  0 0000  40  01 3303 192.168.50.1  192.168.1.10

    36 bytes from 192.168.220.9: Destination Host Unreachable
    Vr HL TOS  Len  ID Flg  off TTL Pro  cks      Src      Dst
    4  5  00 0834 0e37  0 0000  40  01 9036 192.168.50.1  192.168.1.10

    –- 192.168.1.10 ping statistics ---
    3 packets transmitted, 0 packets received, 100.0% packet loss

    Отсюда вопрос. ПОчему удалённая QUAGGA не даёт маршрут пакету бОльшей длины, чем tun-mtu ??



  • Дайте скрины Services: Quagga OSPFd > Global Settings и Interface Settings



  • настройки сервера

    ![2015-08-13 16-07-31 pfsense.localdomain - Services Quagga OSPFd - Google Chrome.png](/public/imported_attachments/1/2015-08-13 16-07-31 pfsense.localdomain - Services Quagga OSPFd - Google Chrome.png)
    ![2015-08-13 16-07-31 pfsense.localdomain - Services Quagga OSPFd - Google Chrome.png_thumb](/public/imported_attachments/1/2015-08-13 16-07-31 pfsense.localdomain - Services Quagga OSPFd - Google Chrome.png_thumb)
    ![2015-08-13 16-10-03 pfsense.localdomain - Services Quagga OSPFd Edit - Google Chrome.png](/public/imported_attachments/1/2015-08-13 16-10-03 pfsense.localdomain - Services Quagga OSPFd Edit - Google Chrome.png)
    ![2015-08-13 16-10-03 pfsense.localdomain - Services Quagga OSPFd Edit - Google Chrome.png_thumb](/public/imported_attachments/1/2015-08-13 16-10-03 pfsense.localdomain - Services Quagga OSPFd Edit - Google Chrome.png_thumb)



  • настройки клиента

    ![2015-08-13 16-11-47 agl.ctr-it.ru - Services Quagga OSPFd Edit - Google Chrome.png](/public/imported_attachments/1/2015-08-13 16-11-47 agl.ctr-it.ru - Services Quagga OSPFd Edit - Google Chrome.png)
    ![2015-08-13 16-11-47 agl.ctr-it.ru - Services Quagga OSPFd Edit - Google Chrome.png_thumb](/public/imported_attachments/1/2015-08-13 16-11-47 agl.ctr-it.ru - Services Quagga OSPFd Edit - Google Chrome.png_thumb)
    ![2015-08-13 16-11-26 agl.ctr-it.ru - Services Quagga OSPFd - Google Chrome.png](/public/imported_attachments/1/2015-08-13 16-11-26 agl.ctr-it.ru - Services Quagga OSPFd - Google Chrome.png)
    ![2015-08-13 16-11-26 agl.ctr-it.ru - Services Quagga OSPFd - Google Chrome.png_thumb](/public/imported_attachments/1/2015-08-13 16-11-26 agl.ctr-it.ru - Services Quagga OSPFd - Google Chrome.png_thumb)



  • http://serverfault.com/questions/434969/ospfd-over-an-openvpn-link-strange-error-in-logs

    I gave up struggling with OpenVPN in tun mode and set up a tap-based OpenVPN. Everything started to work as expected.

    P.s. http://blog.ipspace.net/2009/11/ip-ospf-mtu-ignore-is-dangerous-command.html



  • В General Settings не нужно указывать никакие "Subnet to Route". На сервере и на клиенте в Interface Settins добавьте интерфейсы LAN с той же Area и установленным флажком Interface is passive



  • спасибо за 2 поста выше! Вы оба правы!
    Проблема решена!



  • сглазил….
    сделал tun->tap, поменял настройки OSPF, удалил доп параметры tun-mtu с обоих концов.... пинг в 9к прошёл!
    Но спустя некоторое время - всё вернулось на круги своя  :) попробовал всё вернуть на место и проделать ещё раз - всё равно фрагментации пакета нет.
    Я же правильно понимаю, как вариант можно активировать ip ospf mtu-ignore: disabled ? а как это сделать через веб-pfsense?



  • 2 derwin

    Можно ли еще раз скрины настроек (global settings, interfaces) клиента и сервера, учитывая это :

    В General Settings не нужно указывать никакие "Subnet to Route". На сервере и на клиенте в Interface Settins добавьте интерфейсы LAN с той же Area и установленным флажком Interface is passive

    Спасибо.



  • сервер








  • клиент






  • есть идеи?



  • Может только с пингом что-то не так? У меня те же симптомы в одну сторону (потому что все клиенты Mikrotik), кстати tun, но каких-то проблем со связью не наблюдается.
    В любом случае решение похоже есть. Объявите OpenVPN интерфейсы сервера и клиента явно, через Interfaces > (assign) и разрешите их (галка Enable Interface). Никаких настроек в них делать не надо, только имя задать разве что. Удалите в Quagga OSPFd > Interface Settings старые интерфейсы OpenVPN и добавьте вместо них вновь объявленные.



  • Да, после явного объявления интерфейса в Status > Interfaces убедитесь, что он имеет IP из туннельной сети, а он конечно же не имеет никогда. Тут проще всего перезагрузиться.
    Вообще вся эта связка из OpenVPN + явные интерфейсы + OSPF отличается страшным глючевом потому что все наперебой пихают свои маршруты в RT и например после редактирования настроек OpenVPN клиента/сервера он не поднимается пока не запретишь явный интерфейс, потом поднимается, разрешаешь интерфейс - он не имеет адреса, и все по кругу. Презагрузка как ни странно помогает, как-то они договариваются.



  • эта проблема актуальна для Windows XP, который шлёт 2кб пакет для проверки тикета Kerberos. Тип пакета UDP
    Т.е. компы на этой винде со временем теряют домен AD.



  • IPSec (L2) вместо OpenVPN пробовали ?



  • ещё нет. Обязательно попробую.



  • Только tap сперва.


Log in to reply