larsks's questions

Estou usando o seguinte installerconfigpara automatizar a instalação do FreeBSD (13.2-RELEASE):

export PARTITIONS=DEFAULT
export DISTRIBUTIONS="kernel.txz base.txz"
export HOSTNAME=freebsd
export BSDINSTALL_DISTSITE="https://download.freebsd.org/releases/amd64/13.2-RELEASE"
export INTERFACES=vtnet0
export nonInteractive="YES"

dhclient $INTERFACES

#!/bin/sh
sysrc ifconfig_DEFAULT=DHCP
sysrc sshd_enable=YES

Isso invariavelmente resulta em uma incompatibilidade de soma de verificação ("A soma de verificação para kernel.txz não corresponde..."). Verifiquei que as somas de verificação /usr/freebsd-dist/MANIFESTna imagem do instalador correspondem às somas de verificação dos arquivos contidos em $BSDINSTALL_DISTSITE.

Alguma ideia do que estou perdendo aqui?

Eu tenho um convidado CentOS 8 rodando em um host Fedora 31. O convidado está conectado a uma rede de ponte virbr0, e tem endereço 192.168.122.217. Eu posso fazer login no convidado via ssh nesse endereço.

Se eu iniciar um serviço no convidado escutando na porta 80, todas as conexões do host para o convidado falham assim:

$ curl 192.168.122.217
curl: (7) Failed to connect to 192.168.122.217 port 80: No route to host

O serviço está vinculado a 0.0.0.0:

guest# ss -tln
State    Recv-Q    Send-Q        Local Address:Port        Peer Address:Port

LISTEN   0         128                 0.0.0.0:22               0.0.0.0:*
LISTEN   0         5                   0.0.0.0:80               0.0.0.0:*
LISTEN   0         128                    [::]:22                  [::]:*

Usando tcpdump(no virbr0host ou no eth0convidado), vejo que o convidado parece estar respondendo com uma mensagem ICMP "administrador proibido".

19:09:25.698175 IP 192.168.122.1.33472 > 192.168.122.217.http: Flags [S], seq 959177236, win 64240, options [mss 1460,sackOK,TS val 3103862500 ecr 0,nop,wscale 7], length 0
19:09:25.698586 IP 192.168.122.217 > 192.168.122.1: ICMP host 192.168.122.217 unreachable - admin prohibited filter, length 68

Não há regras de firewall na INPUTcadeia no convidado:

guest# iptables -S INPUT
-P INPUT ACCEPT

A tabela de roteamento no convidado parece perfeitamente normal:

guest# ip route
default via 192.168.122.1 dev eth0 proto dhcp metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.217 metric 100

O SELinux está no modo permissivo:

guest# getenforce
Permissive

Se eu parar sshde iniciar meu serviço na porta 22, tudo funcionará conforme o esperado.

O que está causando a falha dessas conexões?

Caso alguém solicite, a saída completa iptables-savedo convidado é:

*filter
:INPUT ACCEPT [327:69520]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [285:37235]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
*security
:INPUT ACCEPT [280:55468]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [285:37235]
COMMIT
*raw
:PREROUTING ACCEPT [348:73125]
:OUTPUT ACCEPT [285:37235]
COMMIT
*mangle
:PREROUTING ACCEPT [348:73125]
:INPUT ACCEPT [327:69520]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [285:37235]
:POSTROUTING ACCEPT [285:37235]
COMMIT
*nat
:PREROUTING ACCEPT [78:18257]
:INPUT ACCEPT [10:600]
:POSTROUTING ACCEPT [111:8182]
:OUTPUT ACCEPT [111:8182]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A DOCKER -i docker0 -j RETURN
COMMIT

Eu faço muito trabalho de desenvolvimento local com máquinas virtuais (CentOS/RHEL). Em vez de configurar tudo com uma senha de root padrão - que, se exposta à rede, pode ser problemática - gostaria de configurá-los para permitir o login de root sem senha apenas no console serial.

Minha primeira tentativa foi simplesmente substituir o ExecStartcomando padrão por serial-getty@.serviceuma linha de comando usando a --autologinopção:

ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,38400,9600 --noclear --autologin root ttyS0 $TERM

Enquanto isso ignora o login:prompt, ele ainda solicita uma senha de root. Esta parece ser uma limitação do loginprograma no Linux.

Eu também tentei substituir o programa de login padrão por um shell, assim:

ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,38400,9600 --noclear -n -l /bin/bash ttyS0 $TERM

Mas isso entra em conflito com o selinux: enquanto recebo um bashshell, ele não tem acesso a nada:

bash: /root/.bashrc: Permission denied
# ls /etc/systemd
ls: cannot open directory '/etc/systemd': Permission denied

Em outros lugares na rede, as pessoas sugeriram apenas remover o hash de senha de /etc/{password,shadow}, mas é claro que isso resulta em um conjunto diferente de problemas: agora qualquer usuário pode su -sem uma senha.

Alguma ideia de como fazer isso funcionar corretamente?

Eu tenho um sistema Fedora 31 no qual estou usando o iptables-nft. Eu preciso disso porque ainda há um monte de software que espera as iptablesferramentas de linha de comando herdadas. Isso significa que minha configuração nftables tem o conjunto de tabelas correspondente para corresponder à configuração legada:

table ip filter
table ip nat
table ip6 filter
table ip mangle
table ip6 nat
table ip6 mangle

Eu uso um serviço de VPN em contêiner que, antes do nftables, permitiria o mascaramento na minha interface ethernet primária executando algo assim quando a vpn aparecer:

iptables -t nat -A POSTROUTING -s 172.16.254.0/24 -o eth0 -j MASQUERADE

Desde a atualização para o Fedora 31 e iptables-nft, isso não funciona mais. O contêiner (executando alpine) não possui o iptables-nftwrapper de compatibilidade, mas possui o nftpróprio comando.

Não posso usar o nftcli para adicionar regras às tabelas existentes, porque isso quebrará iptables-nft. Mas eu posso criar novas tabelas. Eu estava esperando que eu pudesse aplicar uma configuração como esta:

table ip vpn {
    chain postrouting {
        type nat hook postrouting priority filter; policy accept;
        ip saddr 172.16.254.0/24 oifname "eth0" counter masquerade
    }

    chain forward {
        type filter hook forward priority filter; policy accept;
        ip saddr 172.16.254.0/24 counter accept
    }
}

...mas isso não parece ter nenhum impacto. Ao definir as cadeias nesta tabela para prioridade 0, eu esperava que elas correspondessem antes da tabela herdada nat, mas esse não parece ser o caso.

Existe uma maneira de fazer isso funcionar?