직장에서 외부 네트워크와 통신하는 상황에서 TTL이 0으로 감소하여 부분적인 패킷 손실이 발생하는 것을 발견했습니다. 그러나 일부 트래픽이 도착하고 문제는 일부 연결의 실패로만 나타납니다. 근본 원인은 현재 알려져 있지 않습니다. 문제의 운영 체제는 우리 측의 Linux입니다. 알 수 없지만 외부 네트워크의 Linux일 가능성이 높습니다. 내 동료 중 한 명이 이 경로에 사용되는 프록시 상자에 들어오고 나가는 모든 패킷의 ttl을 다시 작성할 것을 제안했습니다. 이것은 나에게 나쁜 생각인 것 같지만 이유를 알 수 없습니다. TTL 재작성에 대한 통찰력을 가진 사람이 있습니까?
답변1
부인 성명
TTL의 목적은 무한 루프를 방지하고 특정 시간, 즉 TTL이 0에 도달할 때 루프 트래픽이 삭제되도록 허용하는 것입니다. TTL을 재정의하면 이 메커니즘이 트리거되지 않고 노드를 추가하기에 충분한 트래픽이 주입될 때 연결된 노드가 종료될 수 있습니다. 더 많은 루프.
일반적으로 네트워크의 다양한 지점에서 트래픽을 캡처하여 패킷과 해당 TTL에 무슨 일이 일어나고 있는지 확인하는 것이 좋습니다. 특히 TTL 값이 감소하지 않는 한 동일한 패킷이 동일한 지점에 여러 번 나타나는지 확인하는 것이 좋습니다. 루프. 트래픽이 많은 네트워크에서는 어려워 보일 수 있지만 TTL <= 5인 패킷과 같이 캡처가 제한될 수 있습니다.
iptables
어쨌든, 여기에는 목을 매달 수 있을 만큼의 밧줄이 있습니다. Linux에는 다양한 네트워크 계층에서 작동하여 TTL 값을 재정의하는 다양한 도구가 있습니다. 포함tc,iptables그리고nftables. iptables"증분" 작업을 제공하므로 좋은 값이 무엇인지 추측할 필요가 없기 때문에 이것을 사용하겠습니다 . 다음은 밧줄에 매달리기에 관한 그 남자의 관련 인용문입니다:
TTL 필드를 설정하거나 늘리는 것은 매우 위험할 수 있으므로 어떤 경우에도 피해야 합니다.
1씩 증가하면 패킷을 라우팅할 때 수행되는 자동 1 감소가 취소됩니다(링크된 맨페이지에서 increment by more 또는 use 등의 다른 옵션을 선택할 수 있음 --ttl-set 100).
iptables -t mangle -A FORWARD -j TTL --ttl-inc 1
규칙에 추가 일치 항목이 없으면 패킷이 어떤 방향으로든 라우팅될 때마다 규칙이 적용됩니다.