Долгое время у меня была неуловимая проблема с моей сетью.
Я менял маршрутизатор, точку доступа и делал беспроводные соединения проводными в поисках причины снижения производительности, но так и не смог приблизиться к пониманию того, что не так с моей настройкой.
Проблема выражена неопределенно, как «сеть работает медленно», и ни один конкретный симптом проблемы не был достаточно постоянным, чтобы я мог найти ее первопричину.
Моя текущая инфраструктура состоит из:
Виртуальная машина pfsense, работающая на esxi. В настоящее время единственная виртуальная машина, работающая на хосте (Proliant ML110, Core 2 Duo), чтобы исключить другие виртуальные машины как воров производительности. На сервере есть две сетевые карты, одна для WAN и одна для LAN.
Три коммутатора Procurve 1800/1810 на 8 и 24 порта. Две VLAN, одна для LAN и одна для WAN.
Один Ubiquiti Unifi UAP-AC.
Эта сеть обслуживает около 20 единиц с возможностью подключения.
Вчера возникла более насущная проблема, когда я не мог начать смотреть фильм на Netflix, немного погуглив, я нашелздесьпосле обращения в службу поддержки Netflix мне сказали, что проблема не в них, а в моем интернет-провайдере.
Описание там хорошо соответствует проблемам, с которыми я столкнулся: запуск приложения очень медленный, воспроизведение не всегда работает.
Я попробовал отключить Apple-TV и подключить свой Macbook с помощью того же кабеля. На компьютере Netflix работал без сбоев. Запустив тест скорости на этом самом кабеле, я проверил свою пропускную способность на уровне 100 двунаправленных мегабит. Повторное подключение Apple-TV Netflix работать отказался.
Изменение VLAN на порту, к которому подключен Apple TV, с LAN на WAN позволило подключить его напрямую к Интернету с помощью публичного IP-адреса, с помощью которого можно было без проблем транслировать фильм.
Переключение на LAN воспроизведение снова не удалось. Я отключил все, кроме Apple-TV и uplink коммутатора от коммутатора. Подошел к коммутатору с входящим интернетом, отключил все, кроме двух портов pfsense, подключения к оптоволоконному конвертеру и uplink к коммутатору с Apple-TV. После чего смог начать воспроизведение.
В результате я рассудил, что я должен быть в состоянии определить источник проблемы, переподключив все и посмотрев, какой кабель убивает воспроизведение. Ни один не уничтожил. Все продолжало работать, когда все было снова подключено.
Таков был мой опыт каждый раз, когда я пытался выяснить, почему мое соединение работает плохо. На 100 двунаправленных мегабитах оно должно быть довольно быстрым, но я несколько раз отключал Wi-Fi на своем мобильном телефоне, потому что 4G быстрее. Speedtest всегда показывает 100 мегабит.
Стриминг кажется особенно сложным в управлении, зеркалирование моего экрана с помощью airplay практически бесполезно. Воспроизведение музыки с использованием той же технологии работает, но прерывания воспроизведения являются обычным явлением.
Если вчерашний обход брандмауэра, казалось бы, указывал на то, что во всем этом виноват мошенник, то сегодня результаты оказались обратными:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
real 2m23.383s
user 0m0.046s
sys 0m0.253s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
real 0m52.497s
user 0m0.054s
sys 0m0.253s
Кроме того, чтобы попытаться проверить MTU для сети (согласно теории форума Apple), я попробовал выполнить ping с различными размерами пакетов из WAN, мои тесты показали, что большие пакеты плохо проходят через сеть:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1500 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.015s
user 0m0.003s
sys 0m0.003s
Некоторые эксперименты, похоже, подтвердили, что MTU действительно равен 1500 в WAN:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1472 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.497/4.497/4.497/0.000 ms
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.454/4.454/4.454/0.000 ms
real 0m0.034s
user 0m0.003s
sys 0m0.003s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1473 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.018s
user 0m0.001s
sys 0m0.007s
В локальной сети точка останова находится на том же размере пакета, но мне нужно вручную указать, что я не допускаю фрагментации, чтобы пакет не разорвался:
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 68:b5:99:e7:07:a8 brd ff:ff:ff:ff:ff:ff
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::6ab5:99ff:fee7:7a8/64 scope link
valid_lft forever preferred_lft forever
$ ping -c 1 -s 3000 google.se
PING google.se (83.255.235.35) 3000(3028) bytes of data.
3008 bytes from 83.255.235.35: icmp_seq=1 ttl=61 time=82.3 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 82.324/82.324/82.324/0.000 ms
$ ping -c 1 -s 1472 -M do google.se
PING google.se (83.255.235.123) 1472(1500) bytes of data.
1480 bytes from cache.google.com (83.255.235.123): icmp_seq=1 ttl=61 time=74.7 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 74.779/74.779/74.779/0.000 ms
$ ping -c 1 -s 1473 -M do google.se
PING google.se (83.255.235.35) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
--- google.se ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
Я не понимаю, что не так с моей сетью, и не могу понять, как устранить неполадки дальше. Пожалуйста, помогите мне реструктурировать мою диагностику, чтобы я мог избавить сеть от призраков раз и навсегда.
EDIT, относительно моих настроек DNS:
Если я правильно понимаю, это означает, что резолверы Google используются только в качестве резерва, когда назначенный DHCP сервер имен от провайдера недоступен. Это правильно? Или я случайно запрашиваю адреса у сервера имен, который находится далеко-далеко?
Как вы можете видеть ниже, pfsense сначала пытается справиться с разрешением имен самостоятельно, во-вторых и в-третьих, обращаясь к интернет-провайдеру, и только в качестве четвертого и пятого варианта прибегая к помощи Google. Что, на мой взгляд, вполне разумно?
Apple TV имеет назначенные DHCP сетевые настройки и использует шлюз в качестве сервера имен. DHCP-сервер не имеет выделенных настроек DNS, но наследует список серверов имен выше:
EDIT, относительно цикла for:
Причина запуска ping 100 раз, а не один раз со 100 пакетами, заключалась в необходимости выполнять разрешение имен каждый раз, поскольку при ручном запуске ping требовалось разное количество времени, и я подумал, что, возможно, смогу сделать это ощущение более отчетливым, умножив действие на 100.
Учитывая, что Ubuntu имеет следующую конфигурацию:
$ grep nameserver /etc/resolv.conf
nameserver 127.0.1.1
Эта мысль может показаться немного глупой и жесткой...
EDIT, относительно Apple TV:
Я сбросил Apple TV до заводских настроек. Я отключал устройство несколько раз (иногда с немалым гневом в крови).
ИЗМЕНИТЬ, pfSense:
На днях я сбросил настройки pfSense до заводских и включил только самые необходимые его части (dns, dhcp, nat, static dhcp-leases, несколько переадресаций портов), но вчера Netflix все равно перестал воспроизводить видео в середине потока. Проблема снова исчезла, поэтому перезапуск фильма помог.
Интересно, нужен ли Netflix DNS в середине трансляции? Мне кажется, к тому времени об этом уже должны были позаботиться.
И поскольку сервер работает под управлением последней версии pfsense (2.2.2), он используетнесвязанныйпо умолчанию.
То, что резолвер успешно кэширует разрешения, можно проверить, выполнив два последовательных поиска с помощью инструмента диагностики:
Однако разные ответы сбивают меня с толку.
ИЗМЕНИТЬ, МТУ:
MTU установлен на автоматический режим.
EDIT, тест скорости вездехода:
При выполнении теста скорости на Apple TV на pfsense выводится следующий график:
После этого Apple TV сообщает «тест успешно завершен», но только на долю секунды, а затем сообщение меняется на:
Несмотря на ошибку, я могу пользоваться Netflix.
решение1
Обязательно используйте DNS-сервер вашего локального интернет-провайдера, а не какой-либо удаленный DNS-сервис.
Большая часть контента, который вы можете загрузить или транслировать на свой Apple TV, поступает через Akamai CDN (Apple уже много лет является одним из крупнейших клиентов Akamai). Akamai находит ближайший к вам пограничный узел CDN (сервер) на основе того, откуда исходит ваш DNS-поиск, а ваш DNS-поиск обычно исходит от любого локального рекурсивного/разрешающего DNS-сервера, на использование которого вы настроили свое клиентское устройство.
Убедитесь, что ваш Apple TV настроен на использование DNS-серверов вашего локального интернет-провайдера, а не некоторых потенциально удаленных серверов, таких как Google DNS (8.8.8.8 и 8.8.4.4) или Level 3 (4.2.2.x) или OpenDNS или что-то в этом роде. Обратите внимание, что ваш Apple TV может получать свои настройки DNS через DHCP, а ваш DHCP-сервер может быть процессом на вашем маршрутизаторе/шлюзе. Если DHCP-сервер сообщает вашему Apple TV использовать частный IP-адрес вашего шлюза NAT (или другого локального брандмауэра или маршрутизатора) в качестве своего DNS-адреса, это означает, что ваш шлюз NAT действует как DNS-прокси. Если вы хотите продолжать это делать, убедитесь, что этот шлюз NAT использует DNS-серверы вашего локального интернет-провайдера в качествеегоDNS-серверы.
Используя локальный DNS-сервер, Akamai направит вашего клиента на выполнение запросов на загрузку/потоковую передачу с ближайшего к вам сервера Akamai в Швеции, а не, скажем, с какого-либо сервера рядом с центром обработки данных Google в США, где расположен DNS-сервер Google 8.8.8.8.
[Даже если это неверный ответ для вас, он может оказаться верным ответом для других людей, которые задаются этим вопросом, поэтому я все равно оставлю его здесь.]