Redirecionar o tráfego da LAN privada para o servidor interno quando o DNS responde com o IP externo

2

Eu tenho um roteador / firewall mikrotik RB2011. Dentro do firewall eu tenho um servidor web que tem um IP privado (digamos 192.168.1.5)

No lado da WAN do firewall, tenho um IP estático (suponha que seja 192.0.43.10 - www.example.com).

O firewall / roteador está executando o NAT.

Eu tenho uma regra dstnat para passar o tráfego HTTPS para o servidor e isso funciona.

Agora, o problema mais antigo é que, se um PC interno tentar conectar o link , ele não carregará a página com esse erro no chrome:

Google Chrome's connection attempt to www.example.com was rejected. The website may be down or your network may not be properly configured.

Here are some suggestions: Reload this web page later. Check your Internet connection. Reboot any routers, modems or other network devices that you may be using. Add Google Chrome as a permitted programme in your firewall or antivirus software's settings. If it is already a permitted programme, try deleting it from the list of permitted programmes and adding it again. If you use a proxy server, check your proxy settings or contact your network administrator to make sure the proxy server is working. If you don't believe you should be using a proxy server, adjust your proxy settings: Go to the Chrome menu > Settings > + Show advanced settings > Change proxy settings... and make sure your configuration is set to "no proxy" or "direct." Error 102 (net::ERR_CONNECTION_REFUSED): The server refused the connection.

Tradicionalmente, resolvi isso usando uma configuração de DNS dividido ou de DNS duplo, em que as pesquisas de DNS para www.example.com retornaram o IP interno do servidor, e não o externo. No entanto, não tenho o luxo dessa configuração aqui.

Deve haver uma maneira de resolver isso no mikrotik usando uma regra de redirecionamento, mas não tenho certeza de como configurá-lo. Como eu faria isso?

Isso é o que eu tenho na minha tabela nat. Mas, novamente, isso não acontece. Estou executando o tcpdump no servidor, mas posso ver que o e os pacotes não estão realmente alcançando-o.

[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 
    
por Matt 18.03.2013 / 01:43

2 respostas

1

Se o complicado "Hairpin_NAT" não é a sua cena, a solução para os preguiçosos:

simplesmente adicione uma entrada de DNS estática no dispositivo MT que aponta para o servidor local .. classificado. Todas as solicitações locais são resolvidas corretamente, ignorando o roteador, todo o material externo ignora sua entrada de DNS, portanto, a rota dstnat é executada.

/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
    
por 30.04.2014 / 03:57
0

Supondo que você esteja executando seu próprio servidor DNS interno, você pode ter autoridade para a zona "example.com" e encaminhar todas as outras consultas para algo como OpenDNS ou resolvedores públicos do Google (ou atuar como um resolvedor recursivo, que não é Difícil). Em sua zona "example.com" interna autoritativa, você precisará ter registros correspondentes a todos os registros em sua zona autoritativa voltada para o mundo, mas oferecendo os números IP não públicos. O exemplo abaixo demonstra um servidor DNS fornecendo respostas separadas para clientes internos e externos, mantendo o tráfego interno local.

Assim, sua zona não pública (armazenada no arquivo example.com_internal) pode ter a seguinte aparência:

$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  @ 

e sua zona pública (armazenada no arquivo example.com_public) podem parecer

$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

Você configuraria seu servidor de nomes para ser parecido com:

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";
    };
}



Tudo isso é muito improvável e você deve testá-lo em uma configuração de laboratório antes de implantá-lo na produção. Para qualquer coisa em "example.com", suas máquinas obteriam os endereços internos e os clientes obteriam os endereços públicos. Você também precisará configurar um relacionamento mestre-escravo entre seus servidores DNS, para garantir a replicação e a consistência.

    
por 04.10.2014 / 20:31