☰

IPsec VPN을 통해 핑할 때 설명할 수 없는 대기 시간

tag-icon • tag-icon networking vpn ping ipsec delay
IPsec VPN을 통해 핑할 때 설명할 수 없는 대기 시간

호스트를 통해 네트워크 VPN으로 핑을 보낼 때 매 두 번째 핑이 1초씩 지연되고 동시에 VPN 외부의 보안 게이트웨이에 핑을 보내는 데 평균 13밀리초에서 20밀리초 이하가 걸리는 경우, 그 이유는 무엇일까요? 가능한 최대값을 언제 사용해야 합니까 ping -s 1464?
(더 큰 핑이 발생합니다 icmp_seq=1 Frag needed and DF set (mtu = 1492).)

64 bytes from 192.168.178.1: icmp_seq=2301 ttl=64 time=17.6 ms
64 bytes from 192.168.178.1: icmp_seq=2302 ttl=64 time=1034 ms
64 bytes from 192.168.178.1: icmp_seq=2303 ttl=64 time=19.8 ms
64 bytes from 192.168.178.1: icmp_seq=2304 ttl=64 time=1032 ms
64 bytes from 192.168.178.1: icmp_seq=2305 ttl=64 time=18.6 ms
64 bytes from 192.168.178.1: icmp_seq=2306 ttl=64 time=803 ms
64 bytes from 192.168.178.1: icmp_seq=2307 ttl=64 time=19.6 ms
64 bytes from 192.168.178.1: icmp_seq=2308 ttl=64 time=455 ms
64 bytes from 192.168.178.1: icmp_seq=2309 ttl=64 time=19.9 ms
64 bytes from 192.168.178.1: icmp_seq=2310 ttl=64 time=18.4 ms
64 bytes from 192.168.178.1: icmp_seq=2311 ttl=64 time=1052 ms
64 bytes from 192.168.178.1: icmp_seq=2312 ttl=64 time=1019 ms
64 bytes from 192.168.178.1: icmp_seq=2313 ttl=64 time=18.2 ms
64 bytes from 192.168.178.1: icmp_seq=2314 ttl=64 time=1023 ms

패킷이 약간 더 크더라도 상황은 더욱 악화됩니다.

ping -s 234 192.168.178.1
242 bytes from 192.168.178.1: icmp_seq=8 ttl=64 time=23.7 ms
242 bytes from 192.168.178.1: icmp_seq=9 ttl=64 time=18.6 ms
242 bytes from 192.168.178.1: icmp_seq=10 ttl=64 time=2060 ms
242 bytes from 192.168.178.1: icmp_seq=11 ttl=64 time=1043 ms
242 bytes from 192.168.178.1: icmp_seq=12 ttl=64 time=1024 ms
242 bytes from 192.168.178.1: icmp_seq=13 ttl=64 time=41.2 ms
242 bytes from 192.168.178.1: icmp_seq=14 ttl=64 time=2047 ms
242 bytes from 192.168.178.1: icmp_seq=15 ttl=64 time=1042 ms
242 bytes from 192.168.178.1: icmp_seq=16 ttl=64 time=2034 ms
242 bytes from 192.168.178.1: icmp_seq=17 ttl=64 time=1032 ms
242 bytes from 192.168.178.1: icmp_seq=18 ttl=64 time=18.7 ms

IPsec 프로토콜에서 pingICMP가 간섭 없이 통과할 때 네트워크에서 패킷 손실이 발생할 수 있습니까?
그렇다면 이를 디버깅하는 방법은 무엇입니까?

편집: 이는 AVM에서 최근 수정한 문제일 수 있습니다.Fritz-Box의 공개되지 않은 다양한 취약점?

클라이언트는 vpnc 0.5.3r550-3.1LUbuntu 20.04를 사용하고 보안 게이트웨이는 최신 소프트웨어 Fritz-Box 7530을 사용합니다.
다시 시작해도 도움이되지 않았습니다.
동일한 클라이언트 소프트웨어 및 하드웨어는 이러한 지연 없이 ADSL을 통해 동일한 게이트웨이 하드웨어와 작동합니다.
현재 광섬유 네트워크로 전환하면 문제가 발생하는 것 같지만 Fritz-Box의 소프트웨어 업데이트로 인해 문제가 발생할 수도 있습니다.

관련 정보