У меня есть DNS-сервер Bind 9, расположенный за брандмауэром NAT, предположим, что IP-адрес, выходящий на Интернет, - 1.2.3.4
Нет ограничений на исходящий трафик, а порт 53 (TCP / UDP) перенаправляется с 1.2.3.4 на внутренний DNS-сервер (10.0.0.1). Правила IP-таблиц отсутствуют ни на VPS, ни на внутреннем сервере Bind 9.
На удаленном Linux VPS, расположенном в другом месте в Интернете, nslookup отлично работает
# nslookup foo.example.com 1.2.3.4
Server: 1.2.3.4
Address: 1.2.3.4#53
Name: foo.example.com
Addresss: 9.9.9.9
Однако при использовании host на удаленном VPS я получаю следующий вывод:
# host foo.example.com 1.2.3.4
;; reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53
;; reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53
;; connection timed out; no servers could be reached.
С VPS я могу установить соединение (используя telnet) с 1.2.3.4:53
С внутреннего DNS-сервера (10.0.0.1) команда host работает нормально:
# host foo.example.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
foo.example.com has address 9.9.9.9
Любые предложения относительно того, почему команда хоста на моем VPS жалуется на ответ, возвращаемый с другого порта, и что я могу сделать, чтобы это исправить?
Дополнительная информация:
С хоста Windows, внешнего по отношению к сети
>nslookup foo.example.com 1.2.3.4
DNS request timeout
timeout was 2 seconds
Server: UnKnown
Address: 1.2.3.4
DNS request timed out.
timeout was 2 seconds
DNS request timed out.
timeout was 2 seconds
DNS request timed out.
timeout was 2 seconds
DNS request timed out.
timeout was 2 seconds
*** Request to UnKnown timed-out
Это стандартная установка связывания из Ubuntu 12.04 LTS с настроенным около 11 зон.
$ named -v
BIND 9.8.1-P1
Дамп TCP (отфильтрованный) с внутреннего DNS-сервера
20:36:29.175701 IP pc.external.com.57226 > dns.example.com.domain: 1+ PTR? 4.3.2.1.in-addr.arpa. (45)
20:36:29.175948 IP dns.example.com.domain > pc.external.com.57226: 1 Refused- 0/0/0 (45)
20:36:31.179786 IP pc.external.com.57227 > dns.example.com.domain: 2+[|domain]
20:36:31.179960 IP dns.example.com.domain > pc.external.com.57227: 2 Refused-[|domain]
20:36:33.180653 IP pc.external.com.57228 > dns.example.com.domain: 3+[|domain]
20:36:33.180906 IP dns.example.com.domain > pc.external.com.57228: 3 Refused-[|domain]
20:36:35.185182 IP pc.external.com.57229 > dns.example.com.domain: 4+ A? foo.example.com. (45)
20:36:35.185362 IP dns.example.com.domain > pc.external.com.57229: 4*- 1/1/1 (95)
20:36:37.182844 IP pc.external.com.57230 > dns.example.com.domain: 5+ AAAA? foo.example.com. (45)
20:36:37.182991 IP dns.example.com.domain > pc.external.com.57230: 5*- 0/1/0 (119)
Дамп TCP от клиента во время запроса
21:24:52.054374 IP pc.external.com.43845 > dns.example.com.53: 6142+ A? foo.example.com. (45)
21:24:52.104694 IP dns.example.com.29242 > pc.external.com.43845: UDP, length 95
Подводя итог тому, что было ранее написано в комментариях, с некоторыми дополнительными пояснениями:
Похоже, что ваши правила NAT для UDP были нарушены. Индикация - это сообщение об ошибке reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53 и ваш след взят от клиента, где ответ выглядит как dns.example.com.29242 > pc.external.com.43845: UDP, length 95. Исходный порт для пакета ответа должен быть 53, это правильно в вашем дампе, взятом с DNS-сервера (где разрешается в domain для демонстрации).
Хотя некоторые (особенно исторические) преобразователи могут принимать ответы DNS от разных портов / IP-адресов, большинство - нет - в основном из-за соображений безопасности, чтобы препятствовать Атаки с подменой DNS и отравлением кеша.
В любом случае, для трафика UDP NAT без установления соединения ваш маршрутизатор должен сохранить данные состояния из ранее полученного пакета запроса UDP DNS и переназначить кортеж IP: port для ответного пакета обратно на 1.2.3.4:53, чего, по-видимому, нет. Это может быть ошибка конфигурации или ошибка в том, как маршрутизатор обрабатывает таблицу состояний UDP для случаев переадресации портов, поэтому лучше всего будет открыть дело со службой поддержки производителя (обновив код до последней / максимальной версии). заранее - такая проблема, вероятно, была замечена другими пользователями ранее и, таким образом, вероятно, уже будет исправлена).
Хорошо ... ... Я скажу это только один раз ... ... Вы не можете получить доступ к частному DNS через NAT, если NAT не является DNS. Если вам нужно перенаправить порт для доступа к устройству, устройство должно быть настроено для ответа на этом порту. Например, я отправляю DNS-запрос на любой порт в любой DNS в моей внутренней сети, мне не нужен номер порта, потому что они не находятся за NAT, сообщение прямое, и я получаю DNS-поиск с моего локального DNS-сервера. , работающий на портах DNS по умолчанию. Вы отправили запрос через определенный порт во внешнюю сеть. Этот порт является портом ответа DNS по умолчанию? ЕСЛИ нет, я думаю, вы знаете, какой именно. Это было дано вам в сообщении об ошибке. Если возможно, попробуйте настроить DNS-сервер для ответа на определенные номера портов. Настройте его на ответ на 53, как в вашем примере. Если он по-прежнему не отправляется, ваш NAT перенаправляет сообщение на номер исходящего порта. Тот факт, что вы отправляете данные через номер порта на конкретную машину, не означает, что данные возвращаются через тот же номер порта. Порт ответа DNS может быть другим, что является проблемой A, и маршрутизатор отправляет ответ обратно после NAT на открытый порт по обратному адресу, порт, который не обязательно совпадает с входящим портом. Сначала ваше сообщение поступает на маршрутизатор, затем на желаемый порт, затем на машину, на которую этот порт пересылает, затем возвращается через порт ответа на маршрутизатор, который переводит адрес и порт и отправляет его обратно на ваш адрес. Попробуйте запустить порт на маршрутизаторе на стороне DNS. Установите его на открытие порта 53, когда порт 53 включен из-за NAT. Если это не сработает, проверьте свой DNS-сервер и настройте его также на ответ на порт 53. Который Должен позволить обмену сообщениями функционировать. Если это DNS для сети в стиле VPN, VPN должен быть активен, и этот сервер должен перенаправлять порт, в то время как DNS имеет статический адрес в подсети VPN. Теперь вы можете подключить хост-сервер VPN и клиентский сервер, и любой, кто находится за клиентским сервером, может видеть DNS как первичный, со своим интернет-шлюзом в качестве вторичного, а DNS своего провайдера в качестве третичного.