У меня есть серверный микрофон в нашем офисе, который связывается с удаленным сервером через VPN. Были различные проблемы, которые, похоже, были связаны с размером MTU. Майк является сервером RHEL 3, а сервером клиента является CentOS 5. Я использовал инструмент трассировки пути, чтобы попытаться найти максимальный MTU, и получил этот странный результат.
[root@mike root]# tracepath 192.168.1.4
1: mike (192.168.100.1) 0.170ms pmtu 552
1: mike (192.168.100.1) 0.011ms pmtu 552
1: mike (192.168.100.1) 0.010ms pmtu 552
snip - thousands of lines of the same output
1: mike (192.168.100.1) 0.025ms pmtu 552
1: 192.168.100.252 (192.168.100.252) 0.405ms
2: 192.168.100.253 (192.168.100.253) 0.876ms
3: 192.168.1.4 (192.168.1.4) 97.1000ms reached
Resume: pmtu 552 hops 3 back 3
От другого сервера в нашем офисе к другому клиенту я получаю гораздо более разумный результат
[root@nora ~]# tracepath 192.168.2.1
1: nora (192.168.100.228) 0.080ms pmtu 1500
1: 192.168.100.253 (192.168.13.253) asymm 2 0.813ms
2: no reply
3: 192.168.11.1 (192.168.11.1) 73.210ms reached
Resume: pmtu 1500 hops 3 back 3
Так что я думаю, что это как-то связано с микрофоном, а не с промежуточными маршрутизаторами, межсетевыми экранами или VPN. Любые идеи?
В ответ на ответ Дэниела Лоусона ниже, вот почему я считаю, что проблема в серверном микрофоне, поскольку нора может получить правильный ответ.
[root@nora ~]# tracepath 192.168.1.4
1: nora (192.168.100.228) 0.101ms pmtu 1500
1: 192.168.100.253 (192.168.100.253) asymm 2 0.863ms
2: no reply
3: 192.168.1.4 (192.168.1.4) 111.601ms reached
Resume: pmtu 1500 hops 3 back 3
В ответ на комментарий Майка Пеннингтона и 192.168.100.252, и 192.168.100.253 являются межсетевыми экранами. Шлюз по умолчанию - 192.168.100.252, который затем имеет статический маршрут для этих клиентов для отправки трафика на 192.168.100.253. Поскольку они находятся в одной сети, я предполагаю, что именно поэтому счетчик переходов не увеличивается.
Из того, что вы сказали, путь от сервера «mike» к одному клиенту ограничен до 552, а другой путь, от «nora» к другому клиенту, не ограничен.
Вы не сравниваете один и тот же путь, поэтому, если нет дополнительной информации, я сомневаюсь, что это относится к серверу «mike». PMTU - это ограниченный MTU на пути, поэтому, если это было специфично для микрофона, то это должно произойти с любой машиной, к которой вы отслеживаете путь.
Учитывая, что вы используете VPN-соединения, неудивительно, что вы видите ограниченный PMTU. Я бы проверил настройки MTU для конфигурации VPN для первого клиента, а также попытался бы проверить MTU непосредственно для конечной точки VPN клиента (например, общедоступный IP-адрес, который завершает VPN). Тот или другой из них, скорее всего, найдут ваш ответ.
Если у вас под рукой есть машина с Windows, вы можете запустить mturoute в режиме traceroute, чтобы определить, какая ссылка / переход имеет низкий MTU.
Это довольно распространено для брандмауэра и VPN от разных поставщиков, например контрольная точка для уменьшения MTU ниже 1500 для некоторых типов трафика.
Я думаю, что проблема связана с тем, что можжевельник не возвращает значение MTU в пакете недоступности ICMP, который является частью PMTUD. я видел подобную проблему раньше с можжевельником