지난 몇 달 동안 저는 정기적인 인터넷 중단으로 인해 로컬 네트워크의 모든 장치에 영향을 미치고 케이블 모뎀의 전원을 껐다 켜야 했습니다. 오늘 저는 Blizzard의 Battle.net이 포함된 게임을 설치하면 이 문제(또는 동일한 증상이 있는 유사한 문제)를 재현할 수 있다는 것을 알았습니다.
내 대역폭을 포화시키는 것만이 아닙니다.
- 다운로드 자체도 중지됩니다.
- 다운로드 속도를 제한할 때도 이런 현상이 발생합니다.
- 다운로드를 일시 중지해도 자동으로 해결되지 않습니다. 모뎀을 다시 시작하면 도움이 됩니다.
인터넷 연결이 실패하는 시기를 정확히 확인하기 위해 ping 8.8.8.8동일한 네트워크에 연결된 별도의 Linux 노트북(Arch btw를 사용 중)에서 간단한 작업을 실행하고 있습니다. 하지만 인터넷이 실패하더라도 계속 핑을 보낼 수 있습니다! 달리기를 멈출 때만핑, 다시 시작하면 더 이상 응답이 없습니다.
저는 이런 행동에 좀 당황스럽습니다. 나란히 달리기도 해봤는데 계속 ping 8.8.8.8달리는 동안watch -n1 ping -c 1 8.8.8.8핑프로세스가 계속 작동하고핑프로세스가 정기적으로 다시 시작됨보다인터넷이 다운되자마자 실패합니다.
이것이 어떻게 가능한지? "활성 핑 세션"이 중단으로 인해 영향을 받지 않는 것 같습니다. 하지만 레이어 3에서 ICMP를 사용하여 핑을 사용하면 유지하는 것과 유지하는 것 사이에 차이가 있는 이유를 알 수 없습니다.핑새로운 시작을 하는 것과 달리 달리는 것입니다.
Battle.net 다운로드에서도 이 문제가 발생한다는 사실을 확인한 후, 저는 즉시 너무 많은 P2P 연결로 인해 라우터가 막히는 것과 관련된 문제가 있다고 의심했습니다. 하지만 Battle.net이 실제로 P2P를 사용하는지 확실하지 않으며 라우터에서 활성 연결(최대 15,360개 중 최대 3,000~4,000개 연결), 메모리 사용량 등과 관련하여 의심스러운 것이 보이지 않습니다.
안타깝게도 내 ISP가 적절한 인터페이스를 제공하지 않기 때문에 케이블 모뎀의 측정항목을 실제로 볼 수 없습니다. 이것이 내가 브리지 모드에서 실행하는 이유이기도 합니다.
이 행동에 대한 설명이 있습니까?
편집하다: Wireshark를 사용하여 ICMP 메시지를 살펴보았습니다. ICMP 에코 요청이 응답을 받는 것과 그렇지 않은 것 사이에서 눈에 띄는 유일한 차이점은 다음과 같습니다.
- ICMP 식별자는 프로세스에 연결되어 있습니다. 실행중인 요청핑동일한 ID를 가지고 있으면 다시 시작하는 핑 요청에서 새 ID를 얻습니다.
- 실행 중인 요청이 전송될 때마다 시퀀스 번호가 증가합니다.핑, 그러나 다시 시작하는 경우에는 1로 설정됩니다.
이는 매우 예상되는 동작이며 더 이상 나에게 도움이 되지 않습니다. 결국 이로 인해 요청이 다르게 처리되는 이유는 무엇일까요?
답변1
이것이 어떻게 가능한지? "활성 핑 세션"이 중단으로 인해 영향을 받지 않는 것 같습니다. 그러나 레이어 3에서 ICMP를 사용하는 핑을 사용하면 새로 시작하는 것과 달리 핑을 계속 실행하는 것 사이에 차이가 있는 이유를 알 수 없습니다.
UDP 및 ICMP Echo와 같이 명시적인 상태가 없는 프로토콜의 경우에도 라우터는 방화벽 및 NAT 기능에 대해 자체 상태를 유지해야 합니다. (예를 들어, 에코 응답 패킷을 반환할 내부 호스트를 알기 위해 NAT 매핑을 추적합니다.) 이러한 프로토콜의 경우 보내는 첫 번째 패킷이 상태를 설정합니다. 비활성 후 시간 초과로 인해 제거됩니다.
TCP와 마찬가지로 상태 테이블은 UDP 패킷 흐름의 소스-대상 포트 또는 ICMP Echo 흐름의 단일 "요청 ID"를 기억합니다. ICMP에는 포트 번호가 없지만 Echo 요청에는 흐름을 서로 구별하는 동일한 목적을 제공하는 ID가 있습니다. (Wireshark에서 패킷 캡처를 보면 이것을 볼 수 있습니다.) 즉, 각각의 새로운 ping호출로 인해 새로운 상태 항목이 추가됩니다.
(실제 예: 그렇게 하면 conntrack -L컴퓨터의 iptables/nftables 방화벽이 추적한 상태를 볼 수 있습니다. 이는 기본적으로 대부분의 홈 라우터가 내부적으로 사용하는 것과 동일합니다. idICMP Echo 상태 필드를 참고하세요.
따라서 문제 설명에 따르면 라우터의 상태 테이블이 너무 많은 "연결"로 인해 가득 차고 펌웨어가 이전 상태를 푸시하는 대신 새 상태 수락을 중지하도록 구성된 것처럼 들립니다. (공평하게 말하면 나는생각하다그게 Linux conntrack의 기본 동작인가요?)
문제가 있는 라우터에 오류가 발생하지 않도록 하는 버그가 있을 수도 있습니다.청산상태이며 메모리는 재부팅할 때까지 채워집니다. 특히 라우터가 NAT를 하드웨어 가속으로 오프로드하고 해당 오프로드에 손상된 상태 제거가 있는 경우에는 더욱 그렇습니다. (그렇다면 ISP가 일주일에 한 번 재부팅하도록 프로그래밍했다면 전혀 놀랍지 않을 것입니다. 이는 일반 사용자에게 "충분히 좋은" 일입니다.)
Battle.net은 요즘 P2P를 사용하지 않고 단지 CDN의 HTTP일 뿐입니다(오래 전에는 BitTorrent 기반이었지만).하다상대적으로 많은 양의 병렬 HTTP 다운로드를 설정하고 문제의 원인이 될 수 있습니다.
마지막으로 댓글에서도 언급했듯이가능한(가능성은 확실하지 않지만) 라우터의 방화벽이 모든 필터 및/또는 NAT 규칙을 잃어버릴 수 있습니다. 이는 Linux 기반 장치에 적합합니다. 실제로 iptables는 기존 상태에 대해 NAT를 자동으로 처리하므로 어떤 이유로 나가는 SNAT 또는 MASQUERADE 규칙이 제거되면 새 연결이 만들어지지 않지만 기존 연결은 계속 작동합니다. (이미 상태에 저장된 정보에 따라 NAT가 계속 적용됩니다).
이 문제를 해결할 방법을 찾을 수 없다면 VPN이 해결 방법이 될 수 있습니다. 라우터가 볼 수 있는 한 전체 VPN 터널은 하나의 상태로 간주됩니다.