Martin's questions

Eu tenho uma placa-mãe com chipset Intel H97 . O chipset suporta no máximo oito portas USB 2.0 e no máximo seis portas USB 3.0. De acordo com o manual da placa-mãe, ela possui duas portas USB 2.0 e quatro portas USB 3.0 no painel de E/S e o restante das portas USB estão disponíveis através de conectores na placa-mãe. Agora, independentemente de eu conectar os dispositivos USB às portas USB 2.0 ou 3.0 no painel de E/S traseiro ou aos conectores USB na placa-mãe, os dispositivos sempre aparecem no hub raiz do barramento #2. Exemplo onde Mass Storageo tipo de dispositivo está conectado a uma das portas USB no painel de E/S da placa-mãe:

# lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 1: Dev 18, If 0, Class=Communications, Driver=cdc_ether, 480M
    |__ Port 1: Dev 18, If 1, Class=CDC Data, Driver=cdc_ether, 480M
    |__ Port 1: Dev 18, If 2, Class=Mass Storage, Driver=usb-storage, 480M
    |__ Port 12: Dev 27, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
#

Porém, o que são os ônibus #1e #3? #4Para barramento #4parece haver um único Linux Foundation 3.0 root hubtipo de dispositivo conectado:

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Para barramentos #3e #1parece haver um hub Intel USB 2.0 ( ) de 8 portas ( 8pna saída ) e um hub Intel USB 3.0 () de 6 portas conectado:lsusb -t8087:80018087:8009

Bus 003 Device 002: ID 8087:8001 Intel Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8009 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Não sei se isso é uma coincidência, mas o número de portas no hub Intel no barramento #3e no hub Intel no barramento #1soma 14. Isso se alinha com a documentação do chipset e com o número de portas vistas na saída de lsusb -tfor ônibus #2.

nftablessuporta conjuntos preenchidos dinamicamente que são documentados no wiki nftables . O primeiro exemplo na página wiki é o seguinte:

table ip my_filter_table {
        set my_ssh_meter {
                type ipv4_addr
                size 65535
                flags dynamic
        }

        chain my_input_chain {
                type filter hook input priority filter; policy accept;
                tcp dport 22 ct state new add @my_ssh_meter { ip saddr limit rate 10/second } accept
        }
}

nftablesconfiguração acima é explicada da seguinte forma:

Neste exemplo, criamos uma regra para corresponder a novas conexões TCP ssh (porta 22), que usa um conjunto dinâmico chamado my_ssh_meter para limitar a taxa de tráfego a 10 conexões por segundo para cada endereço IP de origem.

Como ler esta regra ou como entendê-la? Quero dizer, os endereços IP de origem ( ip saddr) com limit rate 10/seconddados são adicionados ao conjunto nomeado my_ssh_meterse o subsistema de rastreamento de conexão do Linux detectar uma nova conexão ( ct state new) para a porta de destino TCP 22 ( tcp dport 22). No entanto, parece que o my_ssh_meterconjunto nunca é usado? E a acceptação executada ao preencher o conjunto foi bem-sucedida?

Digamos que eu tenha um servidor com uma eth0interface com endereço IPv4 192.168.0.1/24. Eu tenho um aplicativo em execução neste servidor que precisa se vincular a outro endereço IPv4 na 192.168.0.0/24rede, mas o restante dos aplicativos em execução no servidor precisa continuar usando 192.168.0.1como endereço de origem para conexões de saída. Digamos que esse outro endereço tenha que ser 192.168.0.2. Eu poderia adicionar 192.168.0.2/24e eth0garantir ip route change default via 192.168.0.254 dev eth0 src 192.168.0.1que, por padrão, as conexões de saída sejam usadas 192.168.0.1como endereço de origem. Alternativamente, eu poderia adicionar 192.168.0.2/32em vez de 192.168.0.2/24to eth0e então não preciso tocar na tabela de roteamento.

Existe alguma vantagem em manter o endereço secundário com a mesma máscara de sub-rede do endereço primário? Ou mais especificamente com base no meu exemplo, qual seria a diferença entre configurar 192.168.0.2/32na interface de rede em vez de 192.168.0.2/24?

Eu tenho um pequeno script CGI escrito em Perl que imprime números de 1 a 10 com intervalo de 1 segundo:

root@debian-s-1vcpu-1gb-fra1-01:~# cat /usr/lib/cgi-bin/test
#!/usr/bin/perl

use strict;
local $|=1;

print "Content-encoding: none\nContent-type: text/plain\n\n";
#print "Content-type: text/plain\n\n";

for ( my $i = 1 ; $i <= 10 ; $i++ ) {
    print "$i\n";
    sleep(1);
}
root@debian-s-1vcpu-1gb-fra1-01:~#

O script funciona conforme o esperado ao usar curl:

No entanto, com navegadores da Web (por exemplo, Chromium 88.0.4324.182 ou Firefox 78.13.0esr), a página é carregada por 10 segundos e, em seguida, os números de 1 a 10 são exibidos de uma só vez. Os cabeçalhos de solicitação e resposta de um navegador da Web podem ser vistos abaixo:

Mesmo se eu executar curlcom cabeçalhos de solicitação idênticos ao Firefoxexemplo acima, os números serão impressos com intervalo de 1 segundo como deveriam:

$ curl -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Accept-Encoding:
gzip, deflate' -H 'Accept-Language: en-US,en;q=0.5' -H 'Connection: keep-alive' -H 'Host: 164.90.236.255' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0' -v http://164.90.236.255/cgi-bin/test
* Expire in 0 ms for 6 (transfer 0x55b238016fb0)
*   Trying 164.90.236.255...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b238016fb0)
* Connected to 164.90.236.255 (164.90.236.255) port 80 (#0)
> GET /cgi-bin/test HTTP/1.1
> Host: 164.90.236.255
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Accept-Encoding: gzip, deflate
> Accept-Language: en-US,en;q=0.5
> Connection: keep-alive
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
>
< HTTP/1.1 200 OK
< Date: Mon, 24 Jan 2022 12:19:56 GMT
< Server: Apache/2.4.25 (Debian)
< Content-encoding: none
< Keep-Alive: timeout=5, max=100
< Connection: Keep-Alive
< Transfer-Encoding: chunked
< Content-Type: text/plain
<
1
2
3
4
5
6
7
8
9
10
* Connection #0 to host 164.90.236.255 left intact
$ 

O servidor está Apache 2.4.25com mod_deflatedesabilitado.

O que pode causar tal comportamento? Como desabilitar o buffer de script CGI em navegadores da web? Talvez haja um cabeçalho de resposta que permita controlar esse comportamento.

Digamos que tenha a seguinte topologia de rede:

O gateway NAT linux-routertem a seguinte regra SNAT em vigor:

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  10.99.99.50          anywhere             to:1.1.1.6

Além disso, como visto no desenho, o 1.1.1.6endereço é configurado na lointerface. Tecnicamente, isso não é necessário, ou seja, pode-se excluí-lo e linux-svrainda tem a conectividade. Assim, há um ponto para configurar o endereço de origem SNAT no gateway NAT? Apenas para fins de solução de problemas, pois é mais fácil associar e 1.1.1.6rastrear linux-svr?

É de alguma forma possível substituir uma iptablesregra sem fornecer um número de regra ou inserir/anexar uma regra substituindo a regra existente se a regra adicionada for idêntica a uma já na cadeia? A razão pela qual pergunto é que tenho um script que adiciona iptablesregras automaticamente e pode haver um caso em que a regra adicionada seja idêntica a uma já na cadeia.

Eu tenho uma placa-mãe Supermicro X9DR3-F onde os JWDpinos de jumper 1 e 2 estão em curto e a funcionalidade de watchdog no UEFI está habilitada:

Isso significa que o sistema é redefinido após cerca de 5 minutos se nada redefinir o temporizador do watchdog do hardware. Instalei o watchdogdaemon e configurei para usar o iTCO_wdtdriver:

$ cat /etc/default/watchdog 
# Start watchdog at boot time? 0 or 1
run_watchdog=1
# Start wd_keepalive after stopping watchdog? 0 or 1
run_wd_keepalive=1
# Load module before starting watchdog
watchdog_module="iTCO_wdt"
# Specify additional watchdog options here (see manpage).
$ 

Quando o watchdogdaemon é iniciado, o driver é carregado sem problemas:

$ sudo dmesg | grep iTCO_wdt
[   17.435620] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   17.435667] iTCO_wdt: Found a Patsburg TCO device (Version=2, TCOBASE=0x0460)
[   17.435761] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
$ 

Além disso, o /dev/watchdogarquivo está presente:

$ ls -l /dev/watchdog
crw------- 1 root root 10, 130 Dec  8 22:36 /dev/watchdog
$ 

watchdog-deviceopção na watchdogconfiguração do daemon aponta para este arquivo:

$ grep -v ^# /etc/watchdog.conf 



watchdog-device    = /dev/watchdog
watchdog-timeout   = 60


interval           = 5
log-dir            = /var/log/watchdog
verbose            = yes
realtime           = yes
priority           = 1

heartbeat-file     = /var/log/watchdog/heartbeat
heartbeat-stamps   = 1000
$ 

Para depurar as gravações no dispositivo watchdog, habilitei a heartbeat-fileopção e vejo que as mensagens de manutenção de atividade /dev/watchdogsão enviadas:

$ tail /var/log/watchdog/heartbeat
 1575830728
 1575830728
 1575830728
 1575830733
 1575830733
 1575830733
 1575830733
 1575830733
 1575830733
 1575830733
$ 

No entanto, apesar disso, o servidor se reinicializa com intervalos de aproximadamente cinco minutos.

Meu próximo pensamento foi que talvez o iTCO_wdtdriver controle o watchdog no chipset C606 e o ​​watchdog redefinindo o servidor seja parte do IPMI. Então, certifiquei-me de que o iTCO_wdtdriver não fosse carregado durante a inicialização e reiniciei o servidor. Justo o suficiente, o /dev/watchdognão estava mais presente. Agora eu carreguei o ipmi_watchdogmódulo:

$ ls -l /dev/watchdog
ls: cannot access '/dev/watchdog': No such file or directory
$ sudo modprobe ipmi_watchdog
$ sudo dmesg -T | tail -1
[Tue Dec 10 21:12:48 2019] IPMI Watchdog: driver initialized
$ ls -l /dev/watchdog
crw------- 1 root root 10, 130 Dec 10 21:12 /dev/watchdog
$ 

.. e finalmente iniciei o watchdogdaemon que, com base no /var/log/watchdog/heartbeatarquivo, está gravando /dev/watchdogcom intervalo de 5s. Além disso, pode-se confirmar isso com strace:

$ ps -p 2296 -f
UID        PID  PPID  C STIME TTY          TIME CMD
root      2296     1  0 01:28 ?        00:00:00 /usr/sbin/watchdog
$ sudo strace -y -p 2296
strace: Process 2296 attached
restart_syscall(<... resuming interrupted nanosleep ...>) = 0
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
open("/proc/uptime", O_RDONLY)          = 2</proc/uptime>
close(2</proc/uptime>)                  = 0
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
nanosleep({5, 0}, NULL)                 = 0
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
open("/proc/uptime", O_RDONLY)          = 2</proc/uptime>
close(2</proc/uptime>)                  = 0
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
nanosleep({5, 0}, NULL)                 = 0
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
open("/proc/uptime", O_RDONLY)          = 2</proc/uptime>
close(2</proc/uptime>)                  = 0
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
write(1</dev/watchdog>, "\0", 1)        = 1
nanosleep({5, 0}, ^Cstrace: Process 2296 detached
 <detached ...>
$

watchdogdaemon acima com PID 2296foi iniciado de uma forma que a heartbeat-fileopção in /etc/watchdog.conffoi comentada para reduzir as writechamadas do sistema na saída do strace.

No entanto, o servidor ainda reinicia com intervalos de aproximadamente 300 segundos.

Por que o daemon watchdog não consegue redefinir o timer watchdog de hardware na placa-mãe Supermicro X9DR3-F?

Eu quero que a systemdinstância por usuário inicie uma unidade de serviço a seguir na inicialização:

user.name@svr:~$ systemctl --user cat tmux
# /etc/systemd/user/tmux.service
[Unit]
Description=Start tmux in detached session

[Service]
Type=forking
ExecStart=/usr/bin/tmux new-session -s test -d
ExecStop=/usr/bin/tmux kill-session -t test
Restart=always
RestartSec=1

[Install]
WantedBy=default.target
user.name@svr:~$

A demora está ativada:

user.name@svr:~$ sudo loginctl show-user user.name | grep Linger=
Linger=yes
user.name@svr:~$

No entanto, quando reinicio o servidor, o serviço não é iniciado:

user.name@svr:~$ systemctl --user status tmux
● tmux.service - Start tmux in detached session
   Loaded: loaded (/etc/systemd/user/tmux.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
user.name@svr:~$

Eu posso iniciar o tmuxserviço manualmente systemctl --user status tmuxsem problemas. Além disso, de acordo com systemctl --user statusa systemdprópria instância por usuário está em execução:

user.name@svr:~$ systemctl --user status 
● svr
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Tue 2019-12-03 22:02:41 UTC; 15min ago
   CGroup: /user.slice/user-1000.slice/[email protected]
           └─init.scope
             ├─456 /lib/systemd/systemd --user
             └─462 (sd-pam)
user.name@svr:~$ 

Isso deve significar que não há problemas com a configuração do Linux PAM.

Por que a instância por usuário do systemd não inicia uma unidade de serviço automaticamente?

É possível propagar o status do link da interface Ethernet do convidado para o host, ou seja, se alguém fizer isso ip l set dev eth0 downno convidado, algo será acionado no host? virsh domif-getlink <domain> <int>ou os arquivos de log do qemu não mostram isso.

Estou executando o Apache em um servidor com firewall stateful onde novas conexões de entrada IPv4/IPv6 são permitidas apenas para as portas TCP 80 e 443. O SSH é permitido de alguns hosts confiáveis ​​e apenas algumas mensagens ICMP/ICMPv6 e portas de destino UDP 33434 - 33534( traceroute no modo UDP) são permitidos de todos os lugares. O tráfego de saída não é protegido por firewall. Existe um ponto de execução do IDS (por exemplo, Snort) em tal ambiente no servidor? Se sim, o que isso atenua ou que visibilidade adicional oferece?

Eu tenho um fw.servicearquivo de unidade systemd que é um requisito para networking.service:

# systemctl show networking -p Requires
Requires=system.slice fw.service
# 

Quando o networking.serviceestá no activeestado e eu executo systemctl stop fwe alguns segundos depois systemctl start fw, ele networking.servicefica no inactive (dead)estado. No entanto, quando o networking.serviceestá no activeestado e eu executo systemctl restart fw, o networking.servicetambém é reiniciado.

Esse é um comportamento esperado? Eu pensei que systemctl restarté basicamente systemctl stopseguido por systemctl starte, portanto systemctl start, também deve iniciar o networking.service.

Digamos que eu tenha um tipo de unidade de serviço systemd que contém o seguinte Wants=e as After=instruções:

Wants=foo.service
After=foo.service

Eu realmente preciso especificar o foo.serviceon Wants=se ele já estiver ativado After=? Ou talvez Wants=foo.serviceseja necessário porque se nenhuma unidade especificar o foo.serviceas Wants=ou Requires=, então o foo.servicenão será iniciado?

Eu instalei a máquina virtual Debian de virt-installforma que o convidado tenha uma interface Ethernet chamada vnet0:

$ virsh domiflist git-server
Interface  Type       Source     Model       MAC
-------------------------------------------------------
vnet0      bridge     br-ext     rtl8139     52:54:00:a8:32:d7

$ 

Isso pode ser confirmado ao inspecionar a qemulinha de comando:

-netdev tap,fd=27,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:a8:32:d7,bus=pci.0,addr=0x2

No entanto, há um dispositivo TAP na máquina host com o mesmo vnet0nome:

$ ethtool -i vnet0                                                                                  
driver: tun
version: 1.6
firmware-version: 
expansion-rom-version: 
bus-info: tap
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
$ 

..mas com endereço MAC diferente:

$ ip l sh vnet0                                                                                     
56: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br-ext state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:a8:32:d7 brd ff:ff:ff:ff:ff:ff
$ 

Como exatamente a interface da máquina virtual e o dispositivo TAP na máquina host estão conectados? Ou existe apenas um dispositivo TAP? Se sim, como os endereços MAC são diferentes?

Eu preciso construir um servidor git onde determinados usuários tenham acesso de leitura e gravação ao repositório e o servidor de gerenciamento executando determinados scripts usando este repositório tenha acesso somente leitura ao mesmo repositório no servidor git:

A configuração deve ser o mais segura possível. No momento eu consegui isso com o gitolite onde o devicesrepositório tem a seguinte configuração:

repo devices
    RW     =   eng1
    RW     =   eng2
    RW     =   eng3
    R      =   graphs

O par de chaves SSH para o usuário graphsé armazenado no mgmt-svrservidor no graphsdiretório inicial do usuário e a chave privada é legível e gravável apenas para o usuário graphs. Esta chave privada não é protegida por senha.

Existe uma maneira mais segura de fazer isso? Eu pensei em usar HTTPS para acessar o devicesrepositório no servidor git e autenticação de acesso básico, mas não consigo ver nenhuma vantagem sobre a configuração atual baseada em SSH - ainda preciso armazenar as credenciais de acesso em algum lugar no graphsdiretório inicial do usuário.

Eu tenho um dispositivo virtual ( qcow2imagem) que requer console serial em uma VM. Em outras palavras, não preciso instalar nada. Eu simplesmente preciso inicializar a VM a partir deste qcow2disco e acessar o dispositivo virtual via interface serial. É possível fazer isso com virt-install? Quando eu adiciono o --extra-args="console=ttyS0,115200"to virt-install, ele exige que eu especifique um --location. Existe uma solução alternativa para inicializar uma máquina virtual com serial habilitado usando virt-install, mas não especificando uma fonte de instalação da árvore de distribuição?

iptablesEu tenho regras / bastante complexas ip6tablesque afetam várias interfaces. Gostaria de ter certeza de que as regras de firewall estão sempre em vigor. Como se pode criar regras mesmo para (naquele momento) interfaces inexistentes (por exemplo iptables -A INPUT -i eth999 -j ACCEPT), então pensei que não vou associar as regras a uma interface física, mas sim a uma lointerface que está sempre presente:

# head /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback
        pre-up /sbin/iptables-restore < /etc/network/IPv4_fw_rules
        pre-up /sbin/ip6tables-restore < /etc/network/IPv6_fw_rules
#

Isso tem alguma desvantagem?

Eu tenho uma qemuVM iniciada por um script de orquestração, que cria tapinterfaces transitórias. Quando inspeciono os argumentos da linha de comando do qemu-system-x86_64processo, posso ver que o processo se conecta à tapinterface já aberta com o descritor de arquivo 27:

-netdev tap,fd=27,id=hostnet1,vhost=on,vhostfd=28

Segundo ls -l /proc/<qemu-system-x86_64_PID>/fd/27aponta para /dev/net/tun.

Funciona de alguma forma de forma que o tapnome da interface (por exemplo vnet99) seja passado /dev/net/tuncom ioctl()e isso retorne o fd correto? Ou, em geral, como posso descobrir qual tapinterface em minha máquina host possui o descritor de arquivo 27?

Estou enfrentando um comportamento estranho em que o Chromium (versão 61.0) e o Firefox (versão 54.0) parecem aumentar o zoom por padrão, enquanto outros aplicativos não. Por exemplo, aqui eu tenho o mesmo arquivo de imagem png aberto no navegador da web e no visualizador de imagens feh :

Como visto acima, a imagem em um navegador da web (inserido no README.mdarquivo GitHub) é esticada. No entanto, as configurações de zoom no Chromium e no Firefox são 100%, ou seja, não há zoom in ou out. Quando inspeciono esta imagem com ferramentas de desenvolvedor da Web, a resolução está correta: 880x150px. Eu até criei um novo perfil do Firefox ( firefox -p test) e iniciei o Firefox com --safe-modeesse perfil, mas isso não ajudou.

xrandrsaída pode ser vista abaixo:

$ xrandr 
Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 16384 x 16384
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
DVI-I-1 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 610mm x 350mm
   3840x2160      60.0*+
   2560x1440      60.0  
   1920x1080      60.0     59.9  
   1680x1050      60.0  
   1600x900       60.0  
   1440x900       59.9  
   1280x1024      75.0     60.0  
   1280x800       59.8  
   1280x720       60.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   800x600        75.0     72.2     60.3     56.2  
   640x480        75.0     72.8     59.9  
DP-1 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)
$ 

Quando verifico a mesma página do GitHub com meu laptop (resolução Chromium 63.0 e 1920x1080px), essa imagem não é esticada.

O que pode causar tal comportamento?

O iptablesmódulo multiporta fornece um benefício de desempenho em relação a várias regras separadas? Em outras palavras, é isso:

iptables -A INPUT -p tcp -m multiport --sports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,80 -j ACCEPT

..mais eficiente do que isso:

iptables -A INPUT -p tcp --sport 1 -j ACCEPT
iptables -A INPUT -p tcp --sport 2 -j ACCEPT
iptables -A INPUT -p tcp --sport 3 -j ACCEPT
iptables -A INPUT -p tcp --sport 4 -j ACCEPT
iptables -A INPUT -p tcp --sport 5 -j ACCEPT
iptables -A INPUT -p tcp --sport 6 -j ACCEPT
iptables -A INPUT -p tcp --sport 7 -j ACCEPT
iptables -A INPUT -p tcp --sport 8 -j ACCEPT
iptables -A INPUT -p tcp --sport 9 -j ACCEPT
iptables -A INPUT -p tcp --sport 10 -j ACCEPT
iptables -A INPUT -p tcp --sport 11 -j ACCEPT
iptables -A INPUT -p tcp --sport 12 -j ACCEPT
iptables -A INPUT -p tcp --sport 13 -j ACCEPT
iptables -A INPUT -p tcp --sport 14 -j ACCEPT
iptables -A INPUT -p tcp --sport 80 -j ACCEPT

No primeiro caso, ambos os módulos tcpe multiportsão verificados para cada pacote, mas há uma única regra. No segundo caso, 15 regras são verificadas para cada pacote, mas para cada regra apenas o tcpmódulo é processado.

Eu fiz uma topologia de rede simples a seguir:

server1[eth2] <--> [enp0s31f6]server2

Ambos eth2in server1e enp0s31f6in server2são adaptadores de rede 1GigE e são conectados com cabo Cat5e de 5m. Quando eu baixei um arquivo de 10.000 MiB de server1para server2sem nenhuma regra de firewall, a taxa de transferência foi de 942 Mbps. Então eu gerei 4369 regras como esta:

for i in {1..65535}; do if ((i%15 == 0)); then iptables -A INPUT -p tcp -m multiport --sports $p$i -j ACCEPT; p=; else p=$p$i,; fi; done

Isso significa que havia 4369 multiportregras com 15 portas em cada regra. Por exemplo:

# iptables -L INPUT 1 -v -n --line-numbers 
1        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport sports 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
# iptables -L INPUT 4369 -v -n --line-numbers 
4369     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport sports 65521,65522,65523,65524,65525,65526,65527,65528,65529,65530,65531,65532,65533,65534,65535
# 

Agora, quando executei wget --report-speed=bits -4 -O /dev/null 10.10.10.1:65535em server2, para minha surpresa, a taxa de transferência ainda era de 942 Mbps. Como próximo passo, limpei a INPUTcadeia e gerei 65535 regras como esta:

for i in {1..65535}; do iptables -A INPUT -p tcp --sport $i -j ACCEPT; done

Mais uma vez, executei e agora o throughput caiu wget --report-speed=bits -4 -O /dev/null 10.10.10.1:65535para server2580Mbps. Então, estou correto que, em casos extremos, a multiportabordagem é mais eficiente? Porém, em condições normais sem dezenas de milhares de regras ou dezenas de Gbps de tráfego, não há diferença prática?

Eu vi uma técnica semelhante usada em vários iptablesexemplos para combinar novas conexões:

-A INPUT -p tcp -m tcp --dport 443 --syn -m conntrack --ctstate NEW -j SSH

Como visto acima, as conexões TCP são verificadas em relação aos sinalizadores TCP (SYN deve ser 1 e RST, ACK e FIN 0) por tcpmódulo além --ctstate NEWdo conntrackmódulo. Oferece alguma vantagem sobre isso:

-A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -j SSH

Minha suposição é que sim porque os módulos de correspondência são avaliados na ordem em que são especificados na regra e sem --syn, todos os pacotes TCP para a porta 443 seriam passados ​​de tcpmódulo para conntrackmódulo. Em outras palavras, --syndeve fornecer esse paradigma fail-fast.