cdauth's questions

Como é comum, lxdfornece duas unidades do systemd: lxd.sockete lxd.service. Quando lxd.socketé iniciado, ele inicia lxd.serviceassim que qualquer aplicativo (como lxc) tenta acessar o daemon lxd.

Gostaria lxdde iniciar na inicialização, sem precisar executar nenhum comando. No entanto, quando tento ativar lxd.service, ele ativa lxd.socket:

# systemctl enable lxd.service
Created symlink /etc/systemd/system/sockets.target.wants/lxd.socket → /usr/lib/systemd/system/lxd.socket.

O que está acontecendo aqui? Como posso ativar lxd.service?

O sistema está executando o Fedora 39. Estes são os arquivos da unidade:

/usr/lib/systemd/system/lxd.service:

[Unit]
Description=LXD - main daemon
After=network-online.target openvswitch-switch.service lxcfs.service lxd.socket
Requires=network-online.target lxcfs.service lxd.socket
Documentation=man:lxd(1)

[Service]
Environment=LXD_DOCUMENTATION=/usr/share/doc/lxd-doc/html
Environment=LXD_OVMF_PATH=/usr/share/edk2/ovmf
Environment=LXD_UI=/usr/share/lxd-ui/ui
ExecStart=/usr/bin/lxd --group lxd
ExecStartPost=/usr/bin/lxd waitready --timeout=600
KillMode=process
TimeoutStartSec=600s
TimeoutStopSec=30s
Restart=on-failure
LimitNOFILE=1048576
LimitNPROC=infinity
TasksMax=infinity

[Install]
Also=lxd-containers.service lxd.socket

/usr/lib/systemd/system/lxd.socket:

[Unit]
Description=LXD - unix socket
Documentation=man:lxd(1)

[Socket]
ListenStream=/var/lib/lxd/unix.socket
SocketGroup=lxd
SocketMode=0660
Service=lxd.service

[Install]
WantedBy=sockets.target

Eu tenho um servidor lanserverrodando na minha LAN privada que está conectado a um servidor público publicserverusando o Wireguard. publicserverencaminha conexões TCP para certas portas lanserveratravés da conexão Wireguard usando uma DNATregra iptables.

Em lanserver, o Wireguard é configurado como uma conexão do NetworkManager. Ele está roteando todo o tráfego da Internet através do Wireguard usando AllowedIPs = 0.0.0.0/0, ::/0. Isso faz com que as seguintes regras de ip sejam configuradas em lanserver:

[root@lanserver ~]# ip rule show
0:      from all lookup local
31100:  from all lookup main suppress_prefixlength 0
31101:  not from all fwmark 0xcb2e lookup 52014
32766:  from all lookup main
32767:  from all lookup default
[root@lanserver ~]# ip route show table 52014
default dev wg0 proto static scope link metric 50

Esta configuração funciona corretamente. Uma conexão TCP de entrada publicserveré encaminhada para lanserverusar a regra iptables. A resposta é enviada de volta publicserverporque a regra de ip 31101corresponde a ela.

Há uma exceção: quando tento abrir uma conexão TCP publicserverusando IPv6 do meu computador pessoal pc, que também está dentro da minha LAN privada, não funciona. O problema parece ser que ambos pce lanservertêm um endereço IPv6 na mesma sub-rede pública. publicserverencaminha a conexão para lanservercom sucesso, mas a resposta não é roteada de volta pela conexão Wireguard, mas diretamente para pcdevido à regra de ip 31100.

Como posso garantir que todas as respostas para conexões recebidas pela interface Wireguard lanservertambém sejam enviadas de volta pela interface Wireguard, independentemente de seu IP de origem estar em uma sub-rede local?

Posso pensar em soluções nas seguintes direções:

• Desative o IPv6 lanserver, fazendo com que ele não esteja na mesma sub-rede que o pc. Não é uma solução muito boa.
• Use SNATpara publicservero encaminhamento de porta. Não é uma solução aceitável, pois alguns dos serviços por trás das portas encaminhadas precisam conhecer o verdadeiro IP de origem.
• Mencione explicitamente a sub-rede IPv6 local no AllowedIPspeer do Wireguard. Isso não funciona porque a sub-rede IPv6 muda a cada 24 horas.
• Adicione uma regra de IP personalizada que de alguma forma corresponda a todas as conexões recebidas wg0e use a tabela de roteamento 52014para elas. Não sei exatamente como especificar essa regra. Além disso, o problema é que o número da tabela de roteamento muda toda vez que a conexão Wireguard é reiniciada. O lugar certo para criar tal regra provavelmente seria o PostUpscript, mas o NetworkManager parece não permitir a especificação de um.

Eu gostaria de restringir alguns usuários no meu servidor a apenas poderem executar determinados comandos. Para fazer isso, a abordagem mais comum que encontrei é usar rbash.

Embora eu possa encontrar muitos sites falando sobre rbash, estou tendo problemas para encontrar qualquer informação sobre como usá-lo corretamente. A abordagem mais comum que encontrei foi criar um link simbólico de /bin/rbashpara /bin/bash, definir o shell de login dos usuários restritos para /bin/rbashe, em seguida, definir um personalizado PATHno ~/.bash_profilediretório inicial do usuário.

No entanto, fiquei bastante chocado ao descobrir que, com essa configuração, os usuários ainda podem copiar arquivos para o servidor usando scpe podem até abrir um shell irrestrito usando ssh user@host -t bash! O que parece estar acontecendo é que o servidor SSH está passando o comando para o shell de login no servidor usando -c, então ssh user@host -t bashfaz com que o servidor execute /bin/rbash -c bash, o que funciona porque .bash_profileainda não foi executado para restringir o caminho. scpda mesma forma faz com que o servidor seja executado /bin/rbash -c scp.

Agora me deparei com a ForceCommanddiretiva de sshd. Esta diretiva basicamente sempre faz com que o comando configurado seja passado -cpara o shell de login, ignorando qualquer comando que o cliente tenha especificado. Portanto, se ForceCommandestiver definido como rbash, isso sempre executará o comando /bin/rbash -c rbashno servidor, independentemente de o cliente ter sido chamado com -t bashou como scpou qualquer outra coisa. Infelizmente, /bin/rbash -c rbashfaz com que o .bash_profilenão seja executado, então acabamos com um shell restrito, mas um normal PATH, então podemos simplesmente chamar bashlá para escapar dele.

O que eu gostaria de alcançar:

• Não deve haver como evitar o shell restrito para usuários que se conectam via SSH
• Idealmente, ainda seria possível executar comandos permitidos no shell restrito usandossh user@server permitted_command
• A configuração não deve ser somente SSH, portanto, os usuários que efetuam login, por exemplo, no TTY, também devem ser restritos.

Tenho um host1que possui uma interface WAN eth0( 1.2.3.4) e uma interface LAN eth1( 10.41.82.1). Dentro da LAN está um host2com o endereço IP 10.41.82.2.

As conexões de entrada 1.2.3.4:22são encaminhadas para host2usar as seguintes regras do iptables em host1:

root@host1:~# iptables -t nat -A OUTPUT     -d 1.2.3.4 -p tcp --dport 22 -j DNAT --to 10.41.82.2:22
root@host1:~# iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp --dport 22 -j DNAT --to 10.41.82.2:22

Isso funciona bem, exceto quando host2está tentando acessar 1.2.3.4:22:

root@host2:~# telnet 1.2.3.4 22
Trying 1.2.3.4...

root@host2:~# ping 1.2.3.4
PING 1.2.3.4 56(84) bytes of data.
64 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=0.125 ms
64 bytes from 1.2.3.4: icmp_seq=2 ttl=64 time=0.279 ms

root@host2:~# tcptraceroute 1.2.3.4 22
traceroute to 1.2.3.4, 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
(and so on)

Parece que os pacotes estão sendo encaminhados em um círculo. Como você pode ver, o ping funciona, então as rotas e o encaminhamento de IP estão configurados corretamente.

O que fiz de errado e como posso corrigir o problema?

ATUALIZAR:

Conforme mencionado na resposta de BillThor e conforme descrito no tutorial frozentux no DNAT , preciso adicionar uma SNATregra. Fiz isso agora (observe que adicionei o endereço LAN de host2for -d, pois essa regra é aplicada POSTROUTINGonde o destino do pacote já foi alterado):

root@host1:~# iptables -t nat -A POSTROUTING -d 10.41.82.2 -p tcp --dport 22 -j SNAT --to 10.41.82.1

Infelizmente, isso não resolve o problema e tudo continua igual ao descrito acima. Curiosamente, a SNATregra nunca parece ser correspondida, de acordo com os contadores mostrados ao executar iptables -t nat -nvL.

ATUALIZAÇÃO 2:

Descobri que quando executo tcpdump -i eth1, mesmo quando executo com parâmetros irrelevantes para este caso, como tcpdump -i eth1 port 34238, de repente funciona. Mas apenas enquanto tcpdumpestá em execução.

O que não mencionei até agora porque achei irrelevante é que eth1na verdade é uma ponte e host2é um domínio Xen. Estou começando a suspeitar que meu problema pode estar relacionado a isso.