Lenne's questions

Eu tenho um servidor dedicado de metal bruto do servidor Windows 2012 hospedado em um datacenter. (OVH)

Parece que posso montar um ISO para ser visto como um CD com uma letra de unidade, mas se eu montar uma mídia de instalação do servidor 2016 ou 2019, se eu começar a atualizar para isso, corro o risco de o servidor reinicializar durante a atualização e, em seguida, o mídia não estará disponível, então a atualização é deixada no limbo entre as versões?

Ou devo montar a imagem no java KVM do meu PC? Mesmo quando tenho fibra 1G, o tráfego de rede mostra apenas até 3Mbps, então demora muito para a tela inicial ir para a primeira tela de opção.

Outra opção seria copiar o conteúdo da iso para uma pasta e executar a instalação a partir daí, se possível. É isso?

Tenho um site no IIS onde a autenticação está sendo feita tendo um cabeçalho incluído em todas as páginas asp (clássicas), caso as variáveis ​​de sessão não estejam definidas, o usuário é redirecionado para a página de login, configurando as variáveis ​​de sessão caso o usuário esteja na tabela sql. No entanto, isso não protege recursos como imagens e javascripts que estão sem esse arquivo de cabeçalho.

Então, é possível usar a autenticação básica para realizar uma pesquisa sql em uma tabela de usuário no servidor IIS?

NOTA: os usuários NÃO são usuários sql, são apenas entradas em uma tabela regular.

Simplesmente: Devo redirecionar

http://example.org -> https://www.example.org

http://example.org -> https://example.org -> https://www.example.org

http://example.org -> http://www.example.org -> https://www.example.org

Isso importa? Estou usando HSTS.

Eu dei a um host um endereço 10.0.xx em nosso DNS público. (As razões são irrelevantes)

O host pode ser acessado de nossas localizações através de vpn, no entanto, um site atrás de um Tomato não pode resolver o host.

Eu tentei de um cliente, ping e tracerouting do roteador gui, mas o internal.example.com não foi resolvido.

O DNS no roteador poderia estar interceptando pesquisas de DNS que retornam respostas RFC1918? Poderia o ISP? Mas estou consultando 8.8.8.8, e o domínio é, de acordo com https://www.whatsmydns.net , pode ser resolvido em todo o mundo. (exceto um servidor na Turquia, que retorna 195.175.254.2 para todos os hosts em nosso domínio.)

EDITAR Algo suspeito está acontecendo. O roteador tomato tem uma janela na qual posso executar comandos. Mesmo se eu fizer uma nslookup em um servidor inexistente, Iget responde:

 # nslookup microsoft.com 254.254.254.254
Server:    254.254.254.254 
Address 1: 254.254.254.254

Name:      microsoft.com 
Address 1: 13.77.161.179 
Address 2: 40.76.4.15 
(...) 

Então, algo está definitivamente interceptando as pesquisas de DNS.

Vou ter que perguntar ao meu provedor

Somos um servidor dedicado na OVH, atribuído 2001:41d0:a:72xx::/64

Eu configurei as máquinas em um segmento com ponte para o wan, de acordo com o roteamento público IPv6 de máquinas virtuais do host

O gateway é 2001:41d0:a:72ff:ff:ff:ff:ff, fora da rede

Estamos executando um monte de servidores virtuais debian.

Alguns de nossos servidores (mais antigos) estão felizes em rotear ipv6 para o gateway, mas o novo que estou tentando configurar está dizendo "Destino inacessível; Endereço inacessível" ao fazer ping no gw.

O firewall é configurado igualmente (regras para /64, não no nível do host) e /etc/network/interfaces são iguais; IPv6 são definidos como estáticos. (diferentes endereços de causa)

Em ambas as máquinas funcionando e não funcionando, netstat -rn6|grep eth1 show

2001:41d0:a:72xx::/64          ::                         U    256 2    40 eth1
2001:41d0:a:7200::/56          ::                         UAe  256 2    71 eth1
2001:41d0:a1:72xx::/64         ::                         UAe  256 0     0 eth1
2000::/3                       2001:41d0:a:72ff:ff:ff:ff:ff UG   1024 2 63479 eth1
fe80::/64                      ::                         U    256 0     0 eth1
::/0                           fe80::205:73ff:fea0:1      UGDAe 1024 1     2 eth1
::/0                           fe80::20c:29ff:fe22:60f8   UGDAe 1024 0     0 eth1
ff00::/8                       ::                         U    256 2108951 eth1

Nas máquinas que não funcionam, pingar o gw ou o workd retorna "Destino inacessível".

Todas as máquinas podem alcançar umas às outras na LAN local.

Não sei se é relevante, mas

ping -c3 ff02::2%eth1
64 bytes from fe80::20c:29ff:fedb:a137%eth1: icmp_seq=1 ttl=64 time=0.240 ms
64 bytes from fe80::20c:29ff:fe22:60f8%eth1: icmp_seq=1 ttl=64 time=0.250 ms (DUP!)
64 bytes from fe80::2ff:ffff:feff:fffd%eth1: icmp_seq=1 ttl=64 time=3.57 ms (DUP!)
64 bytes from fe80::2ff:ffff:feff:fffe%eth1: icmp_seq=1 ttl=64 time=5.97 ms (DUP!)

No não trabalho

ping -c3 ff02::2%ens34
PING ff02::2%ens34(ff02::2%ens34) 56 data bytes
64 bytes from fe80::20c:29ff:fedb:a137%ens34: icmp_seq=1 ttl=64 time=0.130 ms
64 bytes from fe80::20c:29ff:fe22:60f8%ens34: icmp_seq=1 ttl=64 time=0.138 ms (DUP!)

Faltam os endereços :ffffd amd :fffe.

Todos os endereços IPv6 foram atribuídos na central da OVH.

TL;DR: Alguma coisa deve estar diferente entre os servidores antigos e novos, mas não consigo encontrar.

ATUALIZAÇÃO: Um clone de uma máquina em funcionamento não funciona.

Do lado de fora do pfsense, configurado como bridge, a máquina manda isso:

12:33:23.087778 IP6 test1.example.org > fe80::2ff:ffff:feff:fffe: ICMP6, neighbor advertisement, tgt is test1.example.org, length 32 12:33:24.106302 IP6 test1.example.org > par10s28-in-x0e.1e100.net: ICMP6, echo request, seq 451, length 64

Mas nada nunca volta. Pings de fora também não passam.

Como a máquina é um clone exacto de uma máquina em funcionamento, excepto os endereços IP, deve ser um problema de upstream na OVH.

ATUALIZAÇÃO 2 Agora a OVH afirma que para encaminhar os dados para um IPv6 é necessário associar o mac a um endereço IPv4. OMG Os IPv6 de trabalho não são.

Se a conexão for apenas entre dois switches, não pode haver colisões. Então, os switches não deveriam ser capazes de lidar com atrasos muito maiores do que os 100m padrão?

Alguns arquivos são compactados em 1.gz

/var/log/apt/history.log.1.gz
/var/log/apt/term.log.1.gz
/var/log/mosquitto/mosquitto.log.1.gz
/var/log/mysql/error.log.1.gz

Alguns não estão zipados, primeiro o segundo nível é 2.gz

/var/log/apache2/access.log.1
/var/log/apache2/error.log.1
/var/log/apache2/other_vhosts_access.log.1
/var/log/dbconfig-common/dbc.log.1
/var/log/exim4/mainlog.1
/var/log/letsencrypt/letsencrypt.log.1

Recebo a mensagem de erro às vezes no correio:

/etc/cron.daily/logrotate:
error: Compressing program wrote following message to stderr 
  when compressing log /var/log/mosquitto/mosquitto.log.1:
gzip: stdin: file size changed while zipping

porque o mosquitto aparentemente grava no log enquanto ele está sendo girado.

O script de rotação é o padrão instalado pelo debian:

/var/log/mosquitto/mosquitto.log {
    rotate 7
    daily
    compress
    size 100k
    nocreate
    missingok
    postrotate
            /usr/bin/killall -HUP mosquitto
    endscript
}

Eu também prefiro o último log descompactado.

Eu configurei hsts para meu domínio no site http://server.mydom.tld:80 , então o navegador vai para a porta https://server.mydom.tld na porta 443

No entanto, também tenho outros servidores web, rodando em outras portas. Então, quando eu vou para http://server.mydom.tld:8888 , ele é encaminhado para https://server.mydom.tld:8888 , mas esse servidor não executa https, então a solicitação falha.

Está de acordo com as especificações?

Percebi que não executo hsts em http://mydom.tld ou http://www.mydom.tld , o que provavelmente é um erro.

O que fazer?

Por que um cabeçalho HSTS não deve ser enviado em HTTP?

O que doeria; os clientes podem entender isso como uma dica para redirecionar para https.

Estou escrevendo CDR para tabela mssql com cdr_adaptive_odbc. Isso funciona bem no sentido de que o registro é gravado após a chamada.

Mas eu gostaria de escrever um cdr_record quando a chamada chegar, antes de ser atendida/abortada.

Motivo: gostaria de adicionar uma função em nosso sistema de CRM: clique neste botão e veja o número de telefone da chamada recebida, onde o registro CDR está "tocando" ou algo assim. Em seguida, combine o número de telefone com os registros do cliente e mostre as informações do chamador na tela.

(não quero empurrar o número para o CRM, tem que ser um pull)

Eu tentei isso:

exten => 13,1,noop()
same => n,forkcdr()
same => n,Wait(2)
same => n,dial(SIP/L13)
same => n,hangup()

mas isso não cria um novo registro no banco de dados.

Eu tenho um /48, e a partir disso atribuí um /64 a esta lan

Eu tenho um Windows 8.1, que quero usar um IP atribuído para endereço de saída.

Mas continuo recebendo um endereço atribuído automaticamente.

netsh interface ipv6>show addresses


Interface 2: Ethernet

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Manual     Preferred     infinite   infinite 2001:DB8:1234:8000::1111:2222
Public     Preferred  29d23h53m20s 6d23h53m20s 2001:DB8:1234:8000:21d:9ff:fe24:656c
Other      Preferred     infinite   infinite fe80::21d:9ff:fe24:656c%2

(2001:DB8:1234:: é a rede de exemplo de documentação)

Eu só quero o endereço 1111:2222 como de saída, não o gerado pelo mac. (Eu quero usar isso como um controle de acesso de primeiro nível)

Desativei as extensões de privacidade:

netsh interface ipv6>show global
Querying active state...

General Global Parameters
---------------------------------------------
Default Hop Limit                   : 128 hops
Neighbor Cache Limit                : 256 entries per interface
Route Cache Limit                   : 128 entries per compartment
Reassembly Limit                    : 33537408 bytes
ICMP Redirects                      : enabled
Source Routing Behavior             : dontforward
Task Offload                        : enabled
Dhcp Media Sense                    : enabled
Media Sense Logging                 : disabled
MLD Level                           : all
MLD Version                         : version3
Multicast Forwarding                : disabled
Group Forwarded Fragments           : disabled
Randomize Identifiers               : disabled
Address Mask Reply                  : disabled
Minimum MTU                         : 1280

Current Global Statistics
---------------------------------------------
Number of Compartments              : 1
Number of NL clients                : 5
Number of FL providers              : 5

netsh interface ipv6>show interface ethernet

Interface Ethernet Parameters
----------------------------------------------
IfLuid                             : ethernet_7
IfIndex                            : 2
State                              : connected
Metric                             : 10
Link MTU                           : 1500 bytes
Reachable Time                     : 22500 ms
Base Reachable Time                : 30000 ms
Retransmission Interval            : 1000 ms
DAD Transmits                      : 1
Site Prefix Length                 : 64
Site Id                            : 1
Forwarding                         : disabled
Advertising                        : disabled
Neighbor Discovery                 : enabled
Neighbor Unreachability Detection  : enabled
Router Discovery                   : enabled
Managed Address Configuration      : disabled
Other Stateful Configuration       : disabled
Weak Host Sends                    : disabled
Weak Host Receives                 : disabled
Use Automatic Metric               : enabled
Ignore Default Routes              : disabled
Advertised Router Lifetime         : 1800 seconds
Advertise Default Route            : disabled
Current Hop Limit                  : 64
Force ARPND Wake up patterns       : disabled
Directed MAC Wake up patterns      : disabled
ECN capability                     : application