Estou tentando implantar pacotes PDQ em computadores conectados ao nosso domínio via VPN, mas o PDQ não consegue encontrar o caminho para o compartilhamento de administrador no computador cliente. Todos os computadores no domínio no trabalho funcionam bem, mas assim que eles se conectam à VPN, o PDQ não consegue se conectar ao compartilhamento.
Tenho uma política de domínio para permitir exceções ICMP e permitir compartilhamento de arquivos e impressoras de entrada configurado para 10.1.22.0/22. Este é o subnet onde estão todos os nossos servidores, incluindo AD, DNS e o servidor PDQ. Ativei essas configurações para o perfil de domínio e o perfil padrão.
A única maneira de o deploy funcionar em computadores VPN é se eu definir a política de grupo de compartilhamento de arquivos e impressoras de entrada para “*” ou “localsubnet”.
Não queremos abrir isso para todos os subnets e não sei por que “localsubnet” funciona.
O PDQ depende bastante do DNS, então verifique se os clientes VPN estão configurados para registrar o IP VPN no DNS.
Como uma observação, muitas das funcionalidades avançadas não funcionam tão bem com computadores em VPN. Batimentos cardíacos, coleções e coisas assim realmente precisam de um endereço IP atualizado no DNS - e a natureza dos computadores VPN significa que eles mudam de IP frequentemente, o que leva bastante tempo para se refletir no PDQ. Só uma advertência ao lidar com essa combinação.
Estão tentando resolver isso com PDQ Link, então você pode verificar essa opção.
Aqui, é necessário fazer uma resolução de problemas básica. Como mencionado, o DNS é amplamente confiável para resolver endereços de computadores. O DNS está configurado corretamente? A configuração de cache de pesquisa está correta? O DNS está registrando o IP corretamente? Quando conectado à VPN, você consulta seus servidores DNS internos com nslookup e ele resolve corretamente o IP do cliente que você está tentando conectar?
Tive problema semelhante há um tempo, não consegui acessar a unidade SMB via VPN IPsec.
Mas o tráfego e a política estão OK, então, após inspecionar o pacote, notei que o tamanho do quadro é muito grande, e sempre após esse quadro muito grande ser enviado ao host SMB, o host não responde, levando ao “age out”. A solução foi reduzir a MTU de 1500 para 1400 na interface física que constrói o IPsec VPN em ambos os lados.
Passei algumas horas tentando fazer minha VPN do Azure registrar seu IP no DNS.
Não consegui obter o IP 172, sempre pegava o endereço 192 do adaptador Wi-Fi no qual a VPN do Azure funciona, não esse adaptador. Descobri que, ao marcar a caixa de seleção contra a VPN do Azure nas configurações de rede, ela verificaria todas as interfaces relacionadas a essa placa física, então tentei desmarcar todos os outros adaptadores e ainda assim o endereço 192 entrava.
Sim, o IP foi atualizado no DNS. O estranho é que tudo funciona quando uso Localsubnet ou “*” para a exceção de faixa de IP na política de domínio. Funciona também quando habilito Compartilhamento de Arquivos e Impressoras (SMB-in) manualmente no cliente, mas não deveria precisar fazer isso em cada cliente. A GPO deveria habilitar o compartilhamento de arquivos.
DNS foi minha primeira suposição também, mas ao ver o OP mencionar que funciona se ele usar curingas na regra de firewall do PDQ, adiei para questões de firewall. O PDQ Link parece interessante. Infelizmente, não usaremos onde trabalho porque usamos F5 para a conectividade VPN e estamos fortemente investidos nisso. Isso dito, acho que a maioria das pessoas usa seu dispositivo VPN para emitir IPs e confia nos computadores para atualizar o DNS. Fizemos isso com nosso Cisco ASA /w AnyConnect. Tínhamos vários sistemas que se conectavam e não atualizavam o DNS por horas, às vezes dias. Para resolver isso, mudamos para o F5 BIGIP Edge Client com APM, configuramos o dispositivo para retransmitir solicitações DHCP ao nosso servidor DHCP interno e deixamos o servidor DHCP cuidar de tudo em nome do cliente. Funciona como um charme. O fato de usarmos DHCP para redes sem fio, com fio e VPN para nossas máquinas clientes significa que o DNS estará sempre atualizado. Eu diria, se puder, deixe de depender de dispositivos de rede para emitir IPs e opte por um servidor DHCP central (clusterizado para failover) para emitir e gerenciar endereços IP, além de gerenciar seu DNS. Se tiver estações de trabalho que requerem IPs estáticos, atribua reservas. A vida será muito mais fácil, especialmente com PDQ.
Você pode tentar adicionar esse subnet à sua regra de firewall. Adicione esse intervalo à sua GPO. Veja se isso resolve o problema. Além disso, se houver um firewall entre as duas zonas, será necessário criar uma regra entre o subnet 10.1.22.0/22 e o subnet 172.16.254.0/24 para permitir as portas que o PDQ precisa para permitir o tráfego.
Faça login no seu firewall. Execute uma busca por tráfego entre seu servidor PDQ e um dispositivo nessa subnet 172. Determine se o firewall está bloqueando ou permitindo o tráfego. Se o tráfego for permitido, mas expira, você pode tentar adicionar essa subnet VPN à regra do firewall do Windows.
Então, tentei adicionar a subnet VPN à política de grupo.
Também pesquisei o tráfego no firewall Palo Alto e parece que o tráfego está permitido, mas expira. Isso significa que o cliente ainda não está aceitando as varreduras ou tráfego do PDQ?
Sim, geralmente. Você precisa manter o Firewall do Windows ativado para a zona do domínio? Normalmente, uso um firewall de rede, ou seja, Palo Alto, para isolar minhas zonas, em vez de usar o Firewall do Windows. Deixo ativado para as zonas Privada e Pública, mas desativo para a zona de Domínio. Acho que o Firewall do Windows é uma dor de cabeça. Suponho que você seguiu as instruções aqui?
Sim, perfis. Nunca achei benefício em rodar firewalls no host (para o perfil de domínio), especialmente se você divide seus subnets em diferentes zonas e envia esse tráfego pelo seu firewall central e controla ACLs na firewall de rede. Na verdade, sempre foi um incômodo para mim porque nossa rede está sempre mudando e precisar modificar regras de firewall na camada de rede e na camada do host fica trabalhoso… especialmente se precisar fazer uma mudança e esperar a GPO propagar. Além disso, tenho várias camadas de segurança na minha rede que compensam não ter o firewall do host ativado em nossos endpoints e seu ambiente pode ser diferente.
Dito isso, estilos diferentes funcionam para diferentes pessoas. Tenho certeza de que algumas pessoas juram pelo firewall no host porque acham que isso impedirá que ransomware se espalhe ou que impedirá que atacantes se movam lateralmente, mas houve casos em que malware infectou máquinas e atacantes conseguiram desativar o firewall na máquina infectada, então qual é o objetivo? Acho que, se 10 sistemas estiverem em uma subnet e um for infectado, os outros estarão protegidos de ataques por várias portas. Tudo isso é ótimo, mas se sua rede estiver bem subnetada, o dano será mínimo. Isso só adiciona mais uma camada de complexidade e mais uma coisa que precisa manter. Execute antivírus na ponta, divida seus subnets em zonas, direcione tudo através do firewall e gerencie suas ACLs na Palo. Essa é a forma que eu gerenciaria, mas se a política da sua empresa for manter o Firewall do Windows ativado, então ignore tudo que acabei de dizer. Sei que não ajuda na sua pergunta original, mas com as informações que você forneceu, não vejo por que o Firewall do Windows ainda bloquearia esse tráfego.
Você pode tentar registrar pacotes descartados no Firewall do Windows. Talvez isso ajude a solucionar o problema.