У меня есть веб-сервер / почтовый сервер apache (работающий в Ubuntu), как показано ниже:
Проблема, с которой я сталкиваюсь, заключается в том, что к веб-сайту abc.com можно получить доступ вне интрасети, но не изнутри.
Маршрутизатор speedport не позволяет вносить какие-либо изменения в маршрутизацию доменного имени.
Это мой файл hosts:
127.0.0.1 localhost localhost.localdomain
127.0.0.1 localhost
#192.168.2.110 marvin.localhost.com marvin
#10.8.0.1 marvin marvin.localhost.com
127.0.0.1 mx.localhost.com.cust.b.hostedemail.com
192.168.2.110 DOMAINNAME.com
# 192.168.2.110 marvin.DOMAINNAME.com marvin
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Раньше это работало нормально в течение года и внезапно перестало работать, что меня озадачивает. Похоже, что в интрасети имя домена не публикуется / не маршрутизируется правильно.
Это побочный эффект использования NAT с IPv4. Ваши клиенты в интрасети получают «внешний» IP-адрес, но этот адрес доступен только извне интрасети.
Есть два решения: первое - расщепленный горизонт DNS. Второе (и, вероятно, гораздо лучшее) решение - развернуть IPv6, который не страдает этой проблемой.
Быстрый обходной путь - обратиться к серверу по его внутренний IP-адрес, а не URL-адрес в Интернете при работе из локальной сети.
Не уверен, что это сработает для вас, но у меня была такая же проблема с виртуальными машинами, работающими с немаршрутизированными IP-адресами и перенаправляющими им внешние IP-адреса. В моей настройке у меня есть сервер Red Hat с KVM. Все виртуальные машины - это 192.168.122.0/24 IP-адреса. Так что я:
extip=172.1.1.7 (the external VIP address I'm forwarding to one of the VMs)
destip=192.168.122.7 (the internal non-routed IP of a VM)
Итак, что происходит, если другая внутренняя виртуальная машина, скажем 192.168.122.5, пытается связаться с 172.1.1.7, эти пакеты действительно перенаправляются на целевую виртуальную машину (192.168.122.7) - но, поскольку исходный IP-адрес 192.168.122.5 , и находится в той же подсети, целевая виртуальная машина отправляет ответные пакеты обратно прямо на этот адрес, не проходя через IP-адрес маршрутизатора (192.168.122.1). Теперь эти пакеты не распознаются исходной виртуальной машиной как часть того же сеанса, поэтому они отбрасываются. Решением было добавить правило POSTROUTING SNAT для перезаписи исходного IP-адреса любого пакета, поступающего из внутренней сети виртуальных машин, которое заставляет ответные пакеты возвращаться обратно через IP-адрес шлюза. Поэтому мои окончательные правила iptables выглядят так:
# Main DNAT routing rule
iptables -t nat -I PREROUTING -p tcp -d ${extip}/32 -j DNAT --to-destination ${destip}
# SNAT rule to handle internal hosts talking to external IP
iptables -t nat -I POSTROUTING -s 192.168.122.0/24 -d ${destip}/32 -p tcp -j SNAT --to-source ${extip}
# Final DNAT rule, so the firewall host can also talk to the external IP
iptables -t nat -I OUTPUT -d ${extip}/32 -p tcp -j DNAT --to-destination ${destip}