OpenVPN + Quagga OSPF нет маршрута при изменении MTU
-
2 сервера подключены между собой по OpenVPN как сервер-клиент.
Туннельная сеть 192.168.220.8/30Локальные сети серверов, которые транслируются в OSPF имеют адресацию 192.168.1.0/24 и 192.168.50.0/24
Проблема такая, опишу пунктами
- поднимаем OpenVPN, и для теста прописываем роуты Local/Remote Network. Всё работает!
- роуты удаляем, поднимаем Quagga OSPF и прописываем туда сети. Появляется проблема - не ходят пакеты более 1472байт. ФРагментация не работает.
- прописываем 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.1036 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.1036 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 сперва.