Вопросы Теги

“выройте +trace fqdn”, и “роют, fqdn” не дают тот же результат на LAN с сервером окон DNS, почему?

в моей компании LAN у меня есть сервер Ubuntu 14.04, работающий в Virtualbox (как гость) в Windows 7 (хост) с соединенным мостом сетевым интерфейсом (таким образом, сервер Ubuntu принадлежит LAN с ее IP: 192.168.1.85). У меня есть веб-сайт на этом сервере: mywebsite.com

Шлюз для LAN к Интернету 192.168.1.1 (Cisco 1841)-> 188.188.188.254 как общедоступный IP.

Существует сервер Windows 2008, который действует как сервер DNS и сервер DHCP на LAN. Я добавил Вперед зона "mywebsite.com" с записью-> 192.168.1.85.

Вне LAN mywebsite.com имеет общедоступные записи DNS, которые указывают на Cisco на общедоступный IP 1841 года (188.188.188.254)

Теперь, когда я проверяю с помощью ping-запросов mywebsite.com от LAN, я быстро добираюсь 192.168.1.85.

Но когда я соединяюсь через браузер на клиентах, это не всегда быстро. Таким образом, я задаюсь вопросом:

Мои запросы действительно/непосредственно разрешены и переданы к 192.168.1.85, ИЛИ они отправляются из LAN и затем передаются назад общественности CISCO 188.188.188.254:80 и NAT к серверу Ubuntu прежде чем быть подаваемым???

Чтобы попытаться ответить на этот вопрос, я искал отслеживание запроса DNS от моего клиента Linux на LAN:

v@v-ss9:~$ dig mywebsite.com
; <<>> DiG 9.9.5-3-Ubuntu <<>> mywebsite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24850
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;mywebsite.com.     IN  A

;; ANSWER SECTION:
mywebsite.com.  3600    IN  A   192.168.1.85

;; Query time: 1 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Aug 22 09:50:16 CST 2014
;; MSG SIZE  rcvd: 66

Этот ответ выглядит правильным: 192.168.1.85. Но затем посмотрите на это:

v@v-ss9:~$ dig +trace mywebsite.com

; <<>> DiG 9.9.5-3-Ubuntu <<>> +trace mywebsite.com
;; global options: +cmd
.           12955   IN  NS  h.gtld-servers.net.
.           12955   IN  NS  g.gtld-servers.net.
.           12955   IN  NS  m.gtld-servers.net.
.           12955   IN  NS  i.gtld-servers.net.
.           12955   IN  NS  l.gtld-servers.net.
.           12955   IN  NS  k.gtld-servers.net.
.           12955   IN  NS  j.gtld-servers.net.
.           12955   IN  NS  d.gtld-servers.net.
.           12955   IN  NS  b.gtld-servers.net.
.           12955   IN  NS  c.gtld-servers.net.
.           12955   IN  NS  a.gtld-servers.net.
.           12955   IN  NS  e.gtld-servers.net.
.           12955   IN  NS  f.gtld-servers.net.
;; Received 516 bytes from 127.0.1.1#53(127.0.1.1) in 18 ms

mywebsite.com.  172800  IN  NS  ns3.rmi.fr.
mywebsite.com.  172800  IN  NS  ns4.rmi.fr.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20140825045016 20140818034016 6122 com. Imq8K9xlvFXlB4IjUkdxOc5YHoTEhqSQUlRSJ9QCIhd9wzGpWJ54AfVf WJ0SUKThalpzqS0cXdLGtNmuYgqLfwUMjpUlT4c+zJyx7I4QMPLImQZh Ov0xy3mUr7dLlymAJYGs9dLI2IaheLvpKTBwaV1gAvo8QEkU8VRiJ7gW 9dk=
U0PIA23FHMVPTKSDHC9PJ1BEA9SIB65R.com. 86400 IN NSEC3 1 1 0 - U0PL33R61V6TCCPBS1171PROP57ASRD9 NS DS RRSIG
U0PIA23FHMVPTKSDHC9PJ1BEA9SIB65R.com. 86400 IN RRSIG NSEC3 8 2 86400 20140825043502 20140818032502 6122 com. qsC5sJbwklao+OedCHpcYo56aQaY0N+7peKmPu8szvjAQoJFRWyuDfAh Nw/gvHXEMzG7tYLriQGVfsiK8GZdPXyG4Ghe1MNN4jOZnSahkT5LjlqL 5QyGC0QiClRMPDAYjUOFGQDkjOJcJYvTNkEyXC2BEpfLI5SwCbYqwqg3 RkE=
;; Received 585 bytes from 192.41.162.30#53(l.gtld-servers.net) in 297 ms

mywebsite.com. 86400 IN A   188.188.188.254
mywebsite.com.  86400   IN  NS  ns3.rmi.fr.
mywebsite.com.  86400   IN  NS  ns4.rmi.fr.
;; Received 204 bytes from 212.51.161.18#53(ns3.rmi.fr) in 310 ms

Здесь я получаю свой IP 188.188.188.254 общественности CISCO!!!

  1. Действительно ли это нормально?
  2. Как знать, общается ли мой браузер (от LAN) действительно непосредственно с 192.168.1.85 при использовании mywebsite.com?

Спасибо за помощь.

0
задан 22 August 2014 в 05:13
1 ответ

Это нормально? ДА!

dig +trace recursively resolves the domain. it starts by requesting the root servers, and so on. Точно так же любой преобразователь по умолчанию ,

Так как сайт размещается в вашей локальной сети, вы можете пропустить рекурсию и обслуживать зону непосредственно с DNS-сервера вашей локальной сети - что вы и делаете. Кроме того, вы можете указать локальный IP-адрес (который не будет работать в публичном интернете) - что вы и делаете. Когда вы опрашиваете домен только с помощью dig, DNS-сервер вашей локальной сети опрашивается напрямую - отсюда локальный IP-адрес в ответе.

С другой стороны, dig +trace игнорирует ваш преобразователь по умолчанию. dig действует как собственный преобразователь и эмулирует то, что мог бы сделать преобразователь в интернете. Так как локальный IP-адрес недоступен из внешнего мира, вам нужен , чтобы вернуть публичный IP-адрес в качестве ответа. И это именно то, что вы видите...

Доступен ли ваш браузер в локальной сети к веб-сайту по локальному IP? PROBABLY! dig возвращает локальный IP. Это указывает на то, что ваш DNS-сервер на самом деле возвращает локальный IP клиентам LAN, и что ваша машина на самом деле настроена на использование LAN DNS-сервера. Итак, запрещая нечто странное, да.

как вы можете быть уверены? Журналы сервера - ваш друг.

Если IP-адрес источника в журналах веб-сервера совпадает с внешним публичным IP-адресом вашего маршрутизатора, то локальный IP-адрес НЕ используется.

С другой стороны, если IP-адрес источника совпадает с локальным IP-адресом вашего браузера, то да, локальный IP-адрес используется.

Как вы можете быть действительно уверены?

Wireshark. Сделайте захват пакетов во время просмотра. Посмотрите, куда идет трафик.

2
ответ дан 4 December 2019 в 13:57

Теги

Похожие вопросы