Google IP가 내 라우터에 TCP(ACK, PSH)를 보냅니다. 이유를 알고 있습니까?

Question

내 트래픽을 모니터링하고 있는데 여러 가지를 발견했습니다.TCP(ACK, PSH) 라우터의 입력 체인에 대한 연결 시도가 방화벽에 의해 삭제되었습니다.

로그는 다음과 같습니다.

Dropping input: src-mac 9c:80:df:a0:8a:dd, proto TCP (ACK,PSH), 172.217.16.78:443 (google ip) ->192.168.1.2:40382 (my router IP), len 115 

내 입력 체인의 마지막 규칙은 패킷을 삭제하는 것이기 때문에 분명히 이것은 삭제되었습니다.

저는 TCP 프로토콜을 충분히 이해하지 못합니다. 조금 순진하다면 죄송합니다. 그런데 요청이 내 라우터로 전달되는 이유는 무엇입니까?

Google 서비스와 제3자 소프트웨어를 사용하는 다양한 장치가 있지만 패킷이 실제로 전송되는 이유는 매우 혼란스럽습니다.에게라우터가 아니라nat'ed내 네트워크의 장치로 전송됩니다(순방향 체인이겠죠?).

Google 제품과 관련하여 내 기기의 경험이 저하된 것을 아직 발견하지 못했습니다. 소프트웨어 업데이트, 푸시 알림 등이 모두 올바르게 작동하는 것 같습니다.

Answer 1

현상은 좀 더 복잡합니다. 나는 해당 로그에서 몇 가지 조사를 수행했으며 궁금해하는 모든 사람들을 위해 여기에서 내 추측을 공유하고 싶습니다.

ACKTCP 플래그 및 (푸시) 가 있는 입력 체인의 삭제를 보여주는 관련 로그 항목입니다 PSH. 이는 네트워크의 일부 서비스가 Google 서버(푸시를 통해)로부터 메시지를 기다리고 있음을 나타냅니다. 그런데 잠깐만요. 패키지가 입력 체인에 기록되는 이유는 무엇일까요? 설명하기가 다소 쉽습니다. 라우터(또는 이미 언급한 @chexum - conntrack)에 NATed/ PATed 트래픽에 대한 연결 정보가 없으면 패키지는 뒤에 있는 장치가 아닌 라우터에 대한 트래픽처럼 보입니다. 이것이 "Google이 라우터로 트래픽을 보내는" 이유를 설명합니다.

그러나 문제는 라우터에 이러한 패키지에 대한 연결 정보가 없는 이유입니다. 그리고 지금은 추측만 할 수 있습니다. 하락은 대부분의 사용자가 인터넷에 접속하는 시간에 관찰됩니다. 내 생각에는 Google의 응답이 오래 걸려서(다른 것보다 푸시 트래픽이 낮기 때문에) 연결 시간이 초과되는 것 같습니다. 이 특정 라우터의 시간 초과는 TCP 패키지의 경우 약 10초이고 SYN. 좀 더 시간이 지나면 conntrack은 오래된 "유효하지 않은" 트래픽에 대한 메모리를 제거하고 그 시점부터 이 연결의 모든 트래픽은 입력 트래픽처럼 보입니다. 이는 유효하지 않은 규칙이 트리거되지 않는 이유 중 하나이기도 합니다.

@samuel은 좀 더 관찰해서 인식할 수 있는 패턴이 있는지 확인해야 한다고 생각합니다. 그러나 일반적으로 나는 이러한 방울이 무시할 수 있다는 @chexum 의견을 말합니다.

Answer 2

소스 포트가 443인 Google IP에서 수신된 패킷이 명확하게 표시됩니다.

물론 누군가가 Google IP 주소를 사용하여 중간자 공격을 할 가능성이 있거나 심지어 Google의 누군가가 귀하에게 패킷을 보낼 가능성도 있습니다. 예, 하지만 이는 매우 그렇습니다.매우할 것 같지 않은.

가능성이 더 높은 것은 귀하의 패킷 필터 및/또는 conntrack 하위 시스템(또는 귀하의 라우터 및/또는 ISP의 유사한 기능)이 이미 google:443과 yourip:40382 사이의 패킷 흐름에서 다음 연결을 보여주는 패킷을 확인했다는 것입니다. 이미 문을 닫았어.

일반적으로 사용자가 시작한 연결은 패킷 필터에 의해 기록되지 않지만 이는 설정된 연결에만 적용됩니다.

FIN양쪽 또는 RST양쪽 에서 연결이 종료되면 해당 연결은 더 이상 고려되지 않습니다 ESTABLISHED. 양쪽에서 지연되거나 재전송되는 모든 패킷은 패킷 필터에 의해 새 패킷으로 간주되고 로그 가치가 있는 것으로 간주됩니다. 특히 제거된 conntrack 항목으로 인해 패킷이 적절한 대상으로 지정되지 않는 경우에는 더욱 그렇습니다.

이는 매우 흔한 일이므로 전혀 걱정할 이유가 없습니다. 일반적으로 기록된 패킷을 안전하게 무시할 수 있습니다.

패턴을 보고 조사하려는 경우 tcpdump시스템에서 유사한 IP 주소의 모든 패킷을 계속 기록할 수 있습니다. 그런 다음 유사한 로그가 하나 더 표시되면 tcpdump를 중지하고 로컬 포트를 필터링하여 확인할 수 있습니다. 실제로 이벤트가 시작되기 몇 초 전에 연결이 열려 있었다면 말이죠.

위의 샘플 tcpdump는 다음과 같습니다.

tcpdump -ieth0 -s0 -w /var/tmp/allssl.cap port 443