Другий пінг упродовж 30 секунд від першого завжди провалюється

Я пінгую хост:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=53.8 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=54.2 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=49.1 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 49.112/52.401/54.202/2.329 ms

І одразу після переривання першої команди ping, я роблю це знову:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms

100% втрата пакетів. Чому?

Це відбувається кожного разу. Тільки чекаючи принаймні 30 секунд (дайте або приймайте секунду) після переривання першого пінгу перед виконанням другого пінгу, другий пінг буде працювати як слід. Виконує пінг раніше минулі 30 секунд призведуть до невдачі пінга (як видно вище), навіть якщо я дозволю йому пробіг через 30 секунд, але 30 секундний "таймер" не буде скинутий.

Pinging різних хостів в першій і другій спробі нічого не змінює.

Запускаючи tcpdump під час тестування, я бачу, що ICMP-ехо відправляється і що відповіді ICMP отримані в обох випадках.

Я також відтворив проблему, використовуючи модуль Net :: Ping Perl, тому проблема не обмежена / bin / ping (якщо Net :: Ping використовує / bin / ping безпосередньо).

Я використовую досить стандартну, поточну установку Debian, яка працює як брандмауер, і робить NAT, використовуючи те, що я вважаю досить стандартними правилами iptables.

linux networking ping

— Jesse Smith
джерело

Що станеться, якщо ви не перериваєте пінг?

— BillThor

Чи я перериваю чи ні, це не має значення. Паралельно запуск двох пінгів дасть подібні результати (другий пінг не працюватиме). Це так, як якщо б перший пінг отримав ексклюзивний доступ до певного унікального ресурсу, необхідного для отримання відповідей ICHO echo.

Можливо, час поглянути на можливості Росії netstat і lsof.

— BillThor

Цілком ймовірно, що ваші ставки обмежені за допомогою ехо-запитів. Вихідна адреса відповідей ICMP щодо невдалих запитів повинна вказати, де ви обмежені.

Обмеження швидкості є відносно тривіальним для налаштування в iptables.

Спроба програми подібна mtr робити пінги повинні показувати, де ви швидко отримуєте обмеження.

EDIT: Переконайтеся, що ви обмежуєте швидкість за допомогою iptables. Можливо, ви захочете оцінити обмеження вхідних запитів ECHO, але якщо вказано неправильно, ви можете обмежити швидкість всіх вхідних пакетів ICMP. Шукати limit у виході iptables -L -n.

— BillThor
джерело

В обох випадках відповіді ICMP виникають у 8.8.8.8, тому, здається, проблема полягає в локальній моїй машині. Я не бачу ніякої відповідної різниці в tcpdump між відповідями, які бачить пінг, і відповідями, які ping не бачить. Десь між tcpdump і ping, вони, здається, зникають.

tcpdump можуть бачити відповіді, які переходять до iptables.

— BillThor

У правилах взагалі немає обмежень. Видалення всіх правил iptables (і скидання політики) тимчасово не допомогло.

Тоді Google або ваш провайдер можуть обмежувати вас.

— LawrenceC