Buga Laza

@AndreyPradoAP Segue instruções específicas para o MikroTik:

Sim, você deve ter um endereço /64 e um bloco /56. Esse bloco pode ser dividido em 256 sub-redes /64. Uma observação: na postagem anterior eu me referi ao seu bloco /56 equivocadamente como se fosse /48. Se desejar aprender mais, recomendo o programa de certificação gratuito da Hurricane Electric disponível em https://ipv6.he.net/certification/.

Não trabalho com MikroTik, especificamente. Mas, de modo geral, o que você precisa é atribuir à sua interface pública o endereço de cliente /64 e gateway fornecidos pelo provedor, e nas interfaces locais um endereço /64 pertencente a esse bloco /48. Esse é o básico para o roteador obter conectividade. Adicionalmente, como o DHCPv6 não atribui aos clientes o endereço do gateway padrão, é necessário habilitar os router advertisements. Se pretende que dispositivos Android obtenham endereços IPv6, será necessário habilitar a atribuição de endereços através de SLAAC, pois esse sistema não possui uma implementação oficial de cliente DHCPv6.

Não seria melhor acessar o DVR através da interface web?

O primeiro passo é verificar se o computador possui conectividade com o destino. No PowerShell, digite o seguinte comando: Test-NetConnection -ComputerName [hostname ou endereço IP] -Port 445

Não existe zona DNS do tipo A. Existem zonas DNS, e nelas encontram-se os resource records (RR), que podem ser de vários tipos, como A, AAAA, SOA, NS, PTR...

Se você não conhece muito sobre o Windows Server, imagino que quem recomendou fazer essa reinstalação conhece menos ainda. O mais correto é tentar sanar essas complicações. Quais seriam?

Já configurou no painel de controle? Idioma português (Brasil), teclado Estados Unidos (internacional).

Não existe nenhum problema em utilizar nomes de domínio válidos na internet, desde que os controladores de domínio possuam endereços IP públicos. Os problemas ocorrem quando não se sabe o que está fazendo. Quanto ao DNS reverso, embora desejável, não interfere na comunicação com o Active Directory. Neste caso, tenho certeza que os NS do domínio matheus.org não apontam para esse servidor. No entanto, acredito que não haveria problemas causados pelo conflito com o domínio homônimo alemão. Dito isso, quase sempre os problemas de ingresso em domínio estão relacionados à resolução DNS. Certifique-se que a estação consegue resolver o nome de um controlador de domínio: Todos os servidores DNS recursivos atribuídos à interface de rede devem ser capazes de alcançar os controladores de domínio e neles resolver os nomes para o domínio em questão, podendo, ou não, serem os próprios servidores que hospedam o Active Directory; Limpe o cache DNS da estação e, se possível, do servidor DNS recursivo.

Pode ser alguma configuração de firewall. Verifique as portas na documentação de referência neste link: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements.

Acredito que seja problema com rota na VPN. Pela descrição, com certeza o servidor Iron é capaz de se comunicar com a rede local. Já se certificou de que os ambos os servidores Ferro e Quartzo são capazes de se comunicar com o servidor na outra ponta da VPN?

Eu não testei, mas creio que o comando abaixo atenda à tua necessidade. New-MailboxExportRequest -Mailbox <MailboxOrMailUserIdParameter> -ContentFilter "(Received -gt <date>) -or (Sent -gt <date>)" -FilePath <LongPath>

Cerca de 15 MB.

Observe que a capacidade de um dos discos é ligeiramente inferior à do outro. Diminua um pouco o tamanho desse volume E, e você deverá ser capaz de criar o espelho sem problemas.

O Windows Defender Firewall (WDF) atua na interface de rede local. Desta forma, normalmente ele é voltado para a proteção na rede interna, a menos que o equipamento esteja diretamente exposto na internet ou a rede local não disponha de nenhuma outra solução de firewall de borda. Caso o WDF seja a única barreira entre a internet e o teu equipamento, ele funciona muito bem, mas torna-se um tanto complexa a manutenção de regras para impedir o tráfego remoto indesejado - cada regra de permissão de entrada configurada automaticamente deverá ser criteriosamente revisada, a fim de especificar os intervalos de endereços autorizados, ou então, alternativamente, pode-se configurar regras de bloqueio de entrada para escopos de endereços externos, o que pode não ser tão simples quanto aparenta.

Para controlar essa quantidade de equipamentos e usuários, o correto é a implantação da autenticação WPA Enterprise. Dessa forma um servidor RADIUS libera o acesso apenas às credenciais autorizadas, sem o compartilhamento de chaves PSK ou cadastro de endereços MAC.

Você deve primeiramente promover o novo servidor como controlador de domínio. Feito isso, os dados do Active Directory serão replicados entre ambos os servidores. Em seguida, basta transferir as FMSO e rebaixar o servidor antigo. O rebaixamento do atual controlador de domínio é opcional e, se atualmente é o único servidor na rede com essa função, avalie a possibilidade de mantê-lo, para fins de redundância.

Então o serviço Servidor DHCP não está instalado nesse servidor, e você está obtendo os endereços de outro equipamento. Você pode descobrir qual é esse equipamento através do comando abaixo: ipconfig /all Ou então através das propriedades da conexão.

Pelo que entendi, esses IP estáticos são definidos manualmente nas estações. Você tem duas alternativas: Excluir do escopo de distribuição as faixas de endereços desejadas; Vincular o endereço MAC no servidor DHCP e deixá-lo entregar sempre o mesmo endereço IP.

É possível gerar log, sim.

E não foi o que eu disse desde o início?

Prezado @arfneto . Estou supondo que esses roteadores secundários estão conectados ao roteador primário através da porta WAN, e possuem sua própria sub-rede na br-lan - se não for isso, não está havendo segmentação da rede, e nem faria sentido o uso de roteadores. Então, obviamente os roteadores podem se comunicar entre si e com a internet, pois as interfaces wan deles estão na mesma sub-rede, ou seja, 10.0.1.0/24. Mas, por definição, cada br-lan deve ter uma sub-rede diferente. Por exemplo, no roteador do primeiro andar, com wan 10.0.1.10, deve ter uma br-lan 10.0.2.0/24. E como você acha que esse roteador saberá onde está o próximo salto para a rede 10.0.3.0/24, se tudo que ele conhece é a rede 10.0.1.0/24 e 10.0.2.0/24? Seria o roteador primário, que só conhece a rede 10.0.1.0/24 e a rede pública?

@arfneto Parece que você nunca fez o que sugere, ou então saberia que: Caso desative o NAT no roteador da operadora, os pacotes enviados terão como endereço de origem um endereço IP privado e serão descartados nos roteadores na internet; É verdade que no lado WAN os roteadores secundários estão na mesma rede; mas essa é a única rede que o roteador principal conhece e, sem a definição das rotas, este será incapaz de determinar qual é o roteador de cada sub-rede, e enviará os pacotes para o seu gateway padrão. @Th0rynn Você pode fazer como o @arfneto disse. Quando descobrir que não funcionou, faça o seguinte: Ative o NAT no roteador da operadora; Se possível, desative o NAT nos roteadores secundários; Adicione as rotas para cada sub-rede no roteador principal. Pode ser que você encontre limitações no roteador fornecido pela operadora ou em roteadores domésticos. O mais recomendado seria um switch com suporte a VLAN e usar o roteador da operadora em modo bridge. Desta forma, não precisaria nem alterar os switchs já existentes nos andares. No entanto, lembre-se que mesmo fazendo tudo isso, se houver algum servidor DHCP não autorizado em sua rede, continuará tendo problemas com conflito de endereços.

A menos que o rapaz tenha disponível um bloco de IP válidos com pelo menos o mesmo número de roteadores, essa é uma ótima maneira para restringir o acesso à internet apenas ao roteador do provedor, impossibilitando o acesso aos demais dispositivos. Todos vão se comunicar, desde que se adicione as devidas rotas no roteador principal. Do contrário, quaisquer pacotes endereçados às outras redes internas serão descartados.

Se existe conflito de endereços com a utilização de um servidor DHCP, vejo dois prováveis motivos: Múltiplos servidores DHCP, autorizados ou não, distribuindo endereços com sobreposição de faixa; Endereços configurados manualmente dentro da faixa de distribuição DHCP. Segmentar a sua rede sem descobrir a causa inicial do problema não vai resolvê-lo, pois ainda poderá ter conflitos de endereços em um ou mais segmentos.