오랫동안 나는 네트워크에 파악하기 어려운 문제를 겪었습니다.
내 설정에 어떤 문제가 있는지 더 이상 이해하지 못한 채 성능 도둑을 찾기 위해 라우터, 액세스 포인트를 변경하고 유선 무선 연결을 만들었습니다.
문제는 "네트워크가 느리게 느껴진다"만큼 모호하며, 근본 원인을 찾을 수 있을 만큼 문제의 특정 증상이 지속되지 않았습니다.
현재 인프라는 다음과 같이 구성되어 있습니다.
Esxi에서 실행되는 pfsense 가상 머신. 현재 성능 도둑인 다른 VM을 제거하기 위해 호스트(Proliant ML110, Core 2 Duo)에서 실행되는 유일한 VM입니다. 서버에는 2개의 NIC가 있는데, 하나는 WAN용이고 다른 하나는 LAN용입니다.
3개의 Procurve 1800/1810 8 및 24 포트 스위치. VLAN 2개(LAN용 1개, WAN용 1개)
하나의 Ubiquiti Unifi UAP-AC.
해당 네트워크는 연결성을 갖춘 20대 단위에 서비스를 제공합니다.
어제 Netflix에서 영화를 시작할 수 없는 좀 더 지속적인 문제가 발생하여 인터넷 검색을 좀 해보니여기Netflix 지원을 받은 후 문제가 Netflix에 있는 것이 아니라 내 ISP에 있다고 말해줍니다.
거기 설명은 제가 겪고 있는 문제와 잘 일치합니다. 앱 시작이 매우 느리고 재생이 항상 작동하는 것은 아닙니다.
Apple-TV를 분리하고 동일한 케이블을 사용하여 Macbook을 연결해 보았습니다. 컴퓨터에서는 Netflix가 문제 없이 작동했습니다. 바로 그 케이블에서 속도 테스트를 실행하여 대역폭이 100MB인 것을 확인했습니다. Apple-TV Netflix를 다시 연결해도 작동이 거부되었습니다.
Apple-TV가 연결된 포트의 VLAN을 LAN에서 WAN으로 변경하면 공인 IP를 통해 인터넷에 직접 연결되어 문제 없이 영화를 스트리밍할 수 있었습니다.
LAN 재생에 다시 넣는 것이 다시 실패했습니다. 스위치에서 Apple-TV와 스위치 업링크를 제외한 모든 연결을 끊었습니다. 인터넷이 들어오는 스위치로 가서 두 개의 pfsense 포트, 광섬유 변환기에 대한 연결 및 Apple-TV가 있는 스위치에 대한 업링크를 제외한 모든 연결을 끊었습니다. 그 후 재생을 시작할 수 있었습니다.
결과적으로 나는 모든 것을 다시 연결하고 어떤 케이블이 재생을 중단시키는지 확인함으로써 문제를 일으키는 원인을 정확히 찾아낼 수 있어야 한다고 생각했습니다. 아무도 그러지 않았습니다. 모든 것이 다시 연결되었을 때 모든 것이 계속 작동했습니다.
연결 성능이 좋지 않은 이유를 알아내려고 할 때마다 이런 경험을 했습니다. 100 메가비트에서는 속도가 더 빨라야 하지만 4G가 더 빠르기 때문에 휴대폰에서 Wi-Fi를 여러 번 꺼 놓았습니다. 속도 테스트에서는 항상 100MB가 표시됩니다.
스트리밍은 특히 처리하기 어려운 것 같습니다. 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 포럼 이론에 따라) 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
일부 실험을 통해 WAN에서 MTU가 실제로 1500임을 확인하는 것 같습니다.
$ 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
LAN에서 중단점은 동일한 패킷 크기에 있지만 패킷 중단에 대한 조각화를 허용하지 않도록 수동으로 지정해야 합니다.
$ 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
내 네트워크에 어떤 문제가 있는지 이해할 수 없으며 문제를 더 이상 해결하는 방법도 알 수 없습니다. 유령 네트워크를 완전히 제거할 수 있도록 문제 해결을 재구성하도록 도와주세요.
편집, 내 DNS 설정과 관련하여:
내가 올바르게 이해했다면 이는 ISP에서 할당한 DHCP 이름 서버를 사용할 수 없는 경우에만 Google 리졸버가 대체 수단으로 사용된다는 의미입니다. 그 맞습니까? 아니면 멀리 떨어져 있는 네임 서버에 무작위로 주소를 요청하는 것입니까?
아래에서 볼 수 있듯이 pfsense는 먼저 이름 확인을 자체적으로 처리하려고 시도하고 두 번째와 세 번째로 ISP에 요청하고 네 번째와 다섯 번째 옵션으로 Google에만 의지합니다. 이것이 제가 보기에는 상당히 합리적으로 보입니다.
Apple TV에는 DHCP 할당 네트워크 설정이 있으며 게이트웨이를 이름 서버로 사용합니다. DHCP 서버에는 전용 DNS 설정이 없지만 위의 이름 서버 목록을 상속합니다.
편집, for 루프와 관련하여 :
100개의 패킷으로 한 번이 아닌 100번 ping을 실행하는 이유는 손으로 실행할 때 ping을 "시작"하는 데 매우 다양한 시간이 걸리는 것처럼 보였기 때문에 매번 이름 확인을 수행하기 위해서였습니다. 액션에 100을 곱하면 그 느낌이 더욱 뚜렷해집니다.
우분투에는 다음과 같은 구성이 있다고 가정합니다.
$ grep nameserver /etc/resolv.conf
nameserver 127.0.1.1
그 생각은 조금 어리석은 생각일 수도 있습니다 ...
편집, Apple TV 관련:
Apple TV를 공장 기본값으로 재설정했습니다. 나는 여러 번 장치의 플러그를 뽑았습니다(때때로 피가 너무 적지 않은 경우도 있었습니다).
편집, pfSense:
일전에 pfSense를 공장 기본값으로 설정하고 더 중요한 부분(dns, dhcp, nat, 정적 dhcp-리스, 몇 가지 포트 전달)만 다시 활성화했지만 어제 Netflix는 여전히 중간 스트림 재생을 중단했습니다. 하지만 문제가 다시 사라졌으므로 영화를 다시 시작해도 효과가 있었습니다.
Netflix에 DNS 미드 스트림이 필요한지 궁금합니다. 그때쯤이면 이미 처리되었어야 할 것 같습니다.
그리고 서버는 최신 pfsense 버전(2.2.2)을 실행하고 있으므로 다음을 사용합니다.매여 있지 않은기본적으로.
해결 프로그램이 해결 방법을 성공적으로 캐싱하고 있는지는 진단 도구를 사용하여 두 번 연속 조회를 수행하여 확인할 수 있습니다.
하지만 다른 대답은 나를 혼란스럽게 만듭니다.
편집, MTU:
MTU는 자동으로 설정됩니다.
편집, ATV 속도 테스트:
Apple TV에서 속도 테스트를 수행하면 pfsense에 다음 그래프가 생성됩니다.
그 후 Apple TV에 "테스트가 성공적으로 완료되었습니다"라는 메시지가 표시되지만 잠시 동안만 다음과 같이 변경됩니다.
오류에도 불구하고 Netflix를 사용할 수 있습니다.
답변1
원격 DNS 서비스가 아닌 로컬 ISP의 DNS 서버를 사용해야 합니다.
Apple TV로 다운로드하거나 스트리밍할 수 있는 대부분의 콘텐츠는 Akamai CDN을 통해 제공됩니다(Apple은 오랫동안 Akamai의 최대 고객 중 하나였습니다). Akamai는 DNS 조회의 출처를 기준으로 가장 가까운 CDN 엣지 노드(서버)를 찾고, DNS 조회는 일반적으로 클라이언트 장치에서 사용하도록 구성한 로컬 재귀/확인 DNS 서버에서 비롯됩니다.
Apple TV가 로컬 ISP의 DNS 서버를 사용하도록 설정되어 있는지 확인하세요. Google DNS(8.8.8.8 및 8.8.4.4), Level 3(4.2.2.x), OpenDNS 또는 이와 유사한 다른 서버가 아닌 잠재적으로 멀리 떨어져 있는 서버를 사용하지 않도록 설정하세요. Apple TV는 DHCP를 통해 DNS 설정을 받을 수 있으며, DHCP 서버는 라우터/게이트웨이의 프로세스일 수 있습니다. DHCP 서버가 Apple TV에 NAT 게이트웨이(또는 다른 로컬 방화벽이나 라우터)의 개인 IP 주소를 DNS 주소로 사용하도록 지시하는 경우 이는 NAT 게이트웨이가 DNS 프록시 역할을 한다는 의미입니다. 계속 그렇게 하려면 해당 NAT 게이트웨이가 로컬 ISP의 DNS 서버를 다음과 같이 사용하고 있는지 확인하세요.그것은DNS 서버.
Akamai는 로컬 DNS 서버를 사용하여 Google의 8.8.8.8 DNS 서버가 있는 미국의 Google 데이터 센터 근처의 일부 서버가 아닌 스웨덴에 있는 가장 가까운 Akamai 서버에서 다운로드/스트리밍 요청을 하도록 클라이언트에 지시합니다. 위치하고 있습니다.
[이것이 당신에게는 정답이 아니더라도 이 질문을 찾는 다른 사람들에게는 정답일 수도 있으므로, 어쨌든 여기에 남겨 두겠습니다.]