O BIND pode alterar uma resposta com base no endereço IP solicitante?

Question

Olá, falha do servidor,

Eu trabalho para um hospital que configurou sua rede usando 192.168.0.0/23 (antes de eu chegar). Estamos querendo que laptops e clientes móveis se conectem de locais remotos usando VPN, mas a rede do hospital entra em conflito muito com a maioria dos roteadores domésticos. Eu tenho pressionado a gestão para nos dar tempo para mudar isso, mas sendo um hospital com servidores / equipamentos / etc todo o lugar isso tem sido impossível de organizar. Então, nós 'corrigimos' o problema usando um nat de 1: 1 de 10.22.0.0/23.

O problema: Os clientes podem se conectar e acessar recursos usando os IPs 10.22.0.0/23 sem problemas, mas se eles consultarem o servidor DNS, receberão as respostas 192.168.0.0/23. Existe uma maneira correta no BIND para traduzi-los rapidamente para endereços 10.22.0.0/23 se a consulta se originar da sub-rede VPN? Ênfase correta, como eu tenho que trabalhar através de vistas BIND usando o seguinte no cron:

sed -e 's/192.168.0./10.22.0./' -e 's/192.168.1./10.22.1./' /var/lib/bind/db.company.local > /var/lib/bind/db.company.local.ext && /usr/sbin/rndc reload company.local in extView

Isso funciona muito bem, mas demora de 15 a 20 minutos, pois o diário BIND leva aproximadamente 15 minutos para gravar no arquivo db.company.local.

Eu li um pouco no RPZ, mas a informação parece irregular. Alguém pode me apontar na direção certa? Se não, você pode tornar minha solução mais elegante?

EDIT: Eu gostaria apenas de deixar claro que eu já estou usando views do BIND, mas estou fazendo isso com duas zonas. Estou gerando minha segunda zona fora do primeiro, enviando-a por meio do sed para alterar os IPs e executando uma atualização do rndc nessa zona nessa visualização. Isso tem um grande atraso, existe uma maneira de usar o mesmo arquivo de zona em ambas as visualizações e alterar a resposta do DNS no momento da consulta?

Obrigado!

    

Answer 1

Isso deve ser um problema no processo. Normalmente, os administradores adicionariam novos registros aos arquivos de zona de ambas as visualizações. Forçá-los a usar scripts se a memória deles estiver ruim. Discipline-os se eles se recusarem a usar os scripts. Mas se é um hospício e você só precisa disso para funcionar, acho que você pode fazer isso com políticas de resposta baseadas em visão.

Digamos que você tenha registros com esta aparência:

$ORIGIN db.company.local.net.
test1   IN A 10.22.0.1
test2   IN A 10.22.1.255

Nas opções de visualização da sua vista de 192space, defina a seguinte política de resposta:

options {
    response-policy { zone "192remap.rpz"; };
}

zone "192remap.rpz" {
    type master;
    file "192remap.rpz.zone";
};

A política de resposta será usada para reescrever todos os IPs de 10 espaços no 192space. Isso é como qualquer outro arquivo de zona, mas os registros NS não têm sentido e os registros têm significados especiais. Como escrever cada remapeamento de endereço IP manualmente seria uma tarefa, usaremos $GENERATE blocos para preencher o arquivo de zona para você.

@            IN    SOA  localhost. root.localhost.  (
                      2   ; serial 
                      3H  ; refresh 
                      1H  ; retry 
                      1W  ; expiry 
                      1H) ; minimum 

             IN    NS    localhost.

; 32.$.0.22.10.rpz-ip. -> 10.22.0.$/32
$GENERATE 0 255 32.$.0.22.10.rpz-ip. A 192.168.0.$
$GENERATE 0 255 32.$.1.22.10.rpz-ip. A 192.168.1.$

Isso não apenas remapeará qualquer um desses 10.22.0.0/23 IPs encontrados na seção RESPOSTA de uma resposta DNS, mas também capturará quaisquer IPs dissimulados que apareçam nas seções AUTHORITY ou ADDITIONAL por qualquer motivo. Uma solicitação para test1.db.company.local.net. (10.22.0.1) deve ter sua resposta reescrita para 192.168.0.1 e somente para os clientes que acessarem sua visualização de 192space.

Espero que isso ajude e deixe-nos saber se funciona. Você pode encontrar mais informações sobre o RPZ e links para a documentação em outra resposta que escrevi há alguns meses.

    

Answer 2

sim, você pode fazer isso com vistas de vinculação:

http://www.zytrax.com/books/dns/ch7/view.html

basicamente, você define cada visualização como uma sub-rede e, em seguida, cada exibição mantém seu próprio arquivo de zona. dependendo da fonte ip / subnet da consulta dns, você terá uma "visão" diferente.

isso é comum para servidores de nomes usarem em uma visão "interna" / "externa", assim como os nomes dns resolvem publicamente na visão externa, mas resolvem "interno" para o ip privado do host na lan interna, quando consultados da (s) lan (s) privada (s) interna (s).