В журналах маршрутизатора я вижу такие записи:
src=8.8.8.8 dst=108.x.y.z ipprot=17 sport=53 dport=54789
Unknown inbound session stopped
8.8.8.8 - это DNS-сервер.
Несколько вопросов по этому поводу:
Почему DNS-сервер пытается связаться со мной?
Нужно ли мне беспокоиться о том, что он не может добраться до места назначения?
Если да, что я могу сделать, чтобы разрешить ему доступ?
Я добавлю обновление о том, почему DNS-сервер может пытаться связаться со мной. В этом случае, после некоторого покопания, я обнаружил, что обнаружение сбоя в маршрутизаторе, стоящем за этим, настроено на использование DNS-серверов, чтобы выяснить, не работает ли одно или другое соединение с ним.
Обновление 2:
Одно из предложений - запустить DNS локально. На самом деле DNS работает локально, и я только что столкнулся с проблемой, связанной с этим, и вернулся, чтобы обновить вопрос.
Видите ли, я вижу ошибки «нет адреса, связанного с именем хоста» в коде приложения, которое пытается связаться с PayPal.
Итак, теперь мне интересно, отображаются ли эти журналы, говорящие мне, что локальный DNS пытается обновить с основного DNS, но не может получить обновления, что означает, что он не может найти внешние API, от которых зависит приложение.
Мысли?
Это рассеяние от запросов, которые ты отправлены, но на которые не был дан ответ вовремя, чтобы ваш брандмауэр с отслеживанием состояния распознал их как часть вашего собственного трафика.
Для трафика UDP каждый межсетевой экран с отслеживанием состояния должен помнить, какой исходящий движение было замечено, так что когда возвращение трафик виден, он знает, что является частью того же потока, и затем разрешен.
По прошествии короткого промежутка времени (или если записи в таблице состояний исчерпываются) он истекает записи для исходящих потоков.
Если ответный пакет слишком поздно, брандмауэр, возможно, забыл об исходном исходящем трафике, поэтому он считает, что входящий пакет является частью нового входящего (и незапрошенного) потока, и блокирует его.
Это обычное дело, здесь не на что смотреть и т.д.