У меня роутер / файервол mikrotik RB2011. Внутри брандмауэра у меня есть веб-сервер с частным IP-адресом (допустим, 192.168.1.5).
На стороне WAN брандмауэра у меня есть статический IP (предположим, 192.0.43.10 - www.example.com).
Межсетевой экран / маршрутизатор работает с NAT.
У меня есть правило dstnat для передачи трафика HTTPS на сервер, и оно работает.
Теперь старая проблема заключается в том, что если внутренний ПК пытается подключиться https://www.example.com ему не удается загрузить страницу с этой ошибкой в chrome:
Попытка подключения Google Chrome к www.example.com была отклонена. Возможно, веб-сайт не работает или ваша сеть настроена неправильно.
Вот несколько предложений: Перезагрузите эту веб-страницу позже. Проверьте подключение к Интернету. Перезагрузите все маршрутизаторы, модемы или другие сетевые устройства, которые вы можете использовать. Добавьте Google Chrome в качестве разрешенной программы в настройках брандмауэра или антивирусного программного обеспечения. Если это уже разрешенная программа, попробуйте удалить ее из списка разрешенных программ и добавить снова. Если вы используете прокси-сервер, проверьте настройки прокси-сервера или обратитесь к администратору сети, чтобы убедиться, что прокси-сервер работает. Если вы не считаете, что вам следует использовать прокси-сервер, измените настройки прокси: перейдите в меню Chrome> Настройки> + Показать дополнительные настройки> Изменить настройки прокси ... и убедитесь, что в вашей конфигурации установлено значение «без прокси» или "прямой". Ошибка 102 (net :: ERR_CONNECTION_REFUSED): сервер отклонил соединение.
Традиционно я решил эту проблему, используя разделенный DNS или двойной тип настройки DNS, когда поиск DNS на www.example.com возвращал внутренний IP-адрес сервера, а не внешний. Однако здесь у меня нет такой роскоши.
Должен быть способ решить эту проблему на микротике с использованием правила предварительной маршрутизации, но я не уверен, как это настроить. Как мне это сделать?
Это то, что у меня в нат-таблице. Но опять же, это не так. Я запускаю tcpdump на сервере, но вижу, что пакеты и фактически не доходят до него.
[admin@MikroTik] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=dstnat action=dst-nat to-addresses=192.168.0.10 protocol=tcp
dst-address=114.134.xxx.xxx in-interface=wan dst-port=22
1 chain=dstnat action=dst-nat to-addresses=192.168.0.10 protocol=tcp
dst-address=114.134.xxx.xxx in-interface=wan dst-port=443
2 chain=srcnat action=masquerade src-address=192.168.0.0/24
dst-address=192.168.0.0/24
3 ;;; default configuration
chain=srcnat action=masquerade to-addresses=114.134.xxx.xxx
out-interface=wan
Если сложная "Шпилька_NAT" не ваша сцена, решение для ленивых:
просто добавьте статическую запись DNS в устройство MT, которая указывает на локальный сервер .. отсортировано. Все локальные запросы разрешаются правильно, минуя маршрутизатор, все внешние данные игнорируют вашу запись DNS, поэтому идет маршрут dstnat.
/ip dns
set allow-remote-requests=yes cache-size=8048KiB servers=\
8.8.8.8,8.8.4.4
/ip dns static
add address=192.168.1.5 name=www.example.com
Предполагая, что у вас есть собственный внутренний DNS-сервер, вы можете быть уполномоченным для зоны «example.com», а затем перенаправлять все остальные запросы на что-то вроде OpenDNS или публичных преобразователей Google (или действовать как рекурсивный преобразователь, что несложно). Во внутренней авторитетной зоне example.com вам необходимо иметь записи, соответствующие всем записям в вашей всемирной авторитетной зоне, но с указанием непубличных IP-адресов. В приведенном ниже примере демонстрируется DNS-сервер, предоставляющий отдельные ответы внутренним и внешним клиентам, сохраняя внутренний трафик локальным.
Итак, ваша непубличная зона (хранящаяся в файле example.com_internal) может выглядеть так:
$TTL 7D
$ORIGIN example.com
@ IN SOA example.com. hostmaster.example.com (
1000001 ; serial number
8H ; refresh interval
2H ; retry interval
4W ; expiration
1D ; minimum
)
@ IN NS dns.example.com
@ IN A 192.168.1.5
dns IN A 192.168.1.3
dns IN A 192.168.1.4
www IN CNAME @
и ваша общедоступная зона (хранящаяся в файле example.com_public) может выглядеть как
$TTL 7D
$ORIGIN example.com
@ IN SOA example.com. hostmaster.example.com (
249590 ; serial number
8H ; refresh interval
2H ; retry interval
4W ; expiration
1D ; minimum
)
@ IN NS dns.example.com
@ IN A 192.0.43.10
www IN CNAME @
dns IN A 192.0.43.10
Затем вы должны настроить свой сервер имен, чтобы он выглядел примерно так:
options {
directory "/var/named";
};
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
};
key "rndc_key" {
algorithm hmac-md5;
secret "ht3pp9a4cik1aq530g6uri06p9g28yrvikqdzr7h";
};
acl internal {
127.0.0.0/8;
192.168.1.0/24;
}
acl external {
!192.168.1.0/24;
!240.0.0.0/4;
}
view internal {
match-clients { internal; };
forwarders {8.8.8.8; 8.8.4.4;} ;
forward only;
zone "0.0.127.in-addr.arpa" {
type master;
file "zone/127.0.0";
allow-query {192.168.1.0/24;};
};
zone "1.168.192.in-addr.arpa" {
type master;
file "zone/192.168.1";
allow-query {192.168.1.0/24;};
};
zone "example.com" {
type master;
file "zone/example.com_internal";
allow-query {192.168.1.0/24;};
};
}
view external {
match-clients { external; };
recursion no;
zone "example.com" {
type master;
file "zone/example.com_public";
};
zone "43.0.192.in-addr.arpa" {
type master;
file "zone/192.0.43";
};
}
Это все очень нестандартно, и вам следует протестировать его в лабораторных условиях, прежде чем развертывать его в производственной среде. Для чего-либо в "example.com" ваши машины получат внутренние адреса, а клиенты - общедоступные. Вам также необходимо будет настроить соединение «главный-подчиненный» между вашими DNS-серверами, чтобы обеспечить репликацию и согласованность.