Robert Koszewski's questions

Tenho uma rede bridge br0 que tem o IP 10.0.0.1/24 , tenho um cliente conectado com o IP 10.0.0.2 a ela. Eu também tenho uma conexão VPN ( tun0 ) que tem um IP atribuído por um DHCP, então o IP pode variar. A conexão VPN não é a rota padrão do sistema, portanto todo o tráfego no dispositivo passa pela rota regular eth0 (não a VPN). (O encaminhamento IPv4 está habilitado no host)

O que estou tentando conseguir é que qualquer cliente que esteja conectado ao br0 (no meu caso um container LXC) com o gateway configurado para 10.0.0.1 tenha seu tráfego NATed e roteado através da conexão VPN.

Como não é possível conectar diretamente o dispositivo tun0 ao br0 , tentei encaminhar o tráfego usando o iptables .

Portanto, as etapas que acredito que devo seguir são forçar o tráfego de br0 a ser mascarado e encaminhado para tun0 usando estes comandos:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i br0 -o tun0 -j ACCEPT

Eu adicionei também rastreamento de estado, mas não funcionou:

iptables -A INPUT -i br0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Para adicionar uma rota padrão secundária, adicionei no arquivo "/etc/iproute2/rt_tables" uma entrada "1 vpnout" e adicionei a rota padrão:

ip route add default dev vpn-out table vpnout

que não funcionou, e o mesmo resultado com os próximos comandos

ip route add default via dev vpn-out table vpnout
ip rule add from 10.0.0.0/24 table vpnout
ip rule add to 10.0.0.0/24 table vpnout

Mas mesmo assim não consigo fazer o ping 8.8.8.8 do Client conectado ao br0 . Há algo que estou perdendo?

Estou tentando persistir (entre reinicializações) rotas e regras do iproute2 no Alpine Linux, até agora sem sucesso.

Aqui estão os comandos:

ip route add default via 192.168.200.1 dev eth1 table net2
ip rule add from 192.168.200.10/24 table net2
ip rule add to 192.168.200.1/32 table net2

Portanto, a maneira correta de fazer isso deve ser teoricamente usando o retorno de chamada "post-up" no arquivo "/etc/network/interfaces" na interface eth1. Então eu adicionei estas linhas à interface:

post-up route add default via 192.168.200.1 dev eth1 table net2
post-up ip rule add from 192.168.200.10/24 table net2
post-up ip rule add to 192.168.200.1/32 table net2

Mas não funciona. Parece que o retorno de chamada nunca é executado. O mesmo acontece com "para cima". Eu tentei um simples "touch /tmp/ok" e o arquivo nunca foi criado.

Alternativamente, tentei criar um script dentro do "/etc/network/if-post-up.d", mas o script é chamado para cada interface que sobe, resultando em entradas repetidas nas regras. Qual seria a maneira certa de fazer isso funcionar corretamente (com isso, quero dizer, execute a regra apenas uma vez quando a interface for ativada e desfaça as regras quando ela for desativada).

Estou tentando usar o FFMPEG para canalizar um fluxo HLS para TVHEADEND. Mas não consigo fazê-lo funcionar, pois continua recebendo alguns erros de host não encontrado, nenhuma rota para host e TLS de handshake.

Para testá-lo, executo este comando substituindo privateurl.com pelo meu URL de streaming privado.

ffmpeg -user_agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100Safari/537.36" -i "https://privateurl.com:8443/stream/stream.m3u8" -c copy -f mpegts test.ts

Isso funciona perfeitamente no Windows (FFMPEG build 3.4.2), mas no meu servidor Debian (Proxmox) não consigo ter uma conexão estável com exatamente o mesmo comando. Eu testei com FFMPEG versão 3.2.12-1~deb9u1 e com ffmpeg versão 3.4.4 dentro de um container LXC com o mesmo resultado em ambos os casos. Como o HLS é feito de pedaços de fluxos ts menores, parece que ele aleatoriamente não consegue se conectar a alguns dos pedaços alegando diferentes tipos de erros que parecem uma conexão ruim com o servidor, mas por quê? Tanto o Windows quanto o Linux Server estão conectados ao mesmo Roteador, e o Servidor está mesmo conectado diretamente via ethernet (Tentei até trocar o cabo) mas ainda não consegue ter uma conexão estável com o stream. Intermitentemente, ele é capaz de conectar e transmitir um chunck, mas depois pára aleatoriamente em outros pedaços.

...
[tls @ 0x7f49f08eea40] The specified session has been invalidated for some reason.
[tcp @ 0x55efbe455aa0] Connection to tcp://privateurl.com:8443 failed (Host is unreachable), trying next address
    Last message repeated 1 times
[hls,applehttp @ 0x7f49f08ee160] Opening 'https://privateurl.com:8443/stream/stream_982112.ts' for reading
[tcp @ 0x55efbe02fbc0] Connection to tcp://privateurl.com:8443 failed (Host is unreachable), trying next address
    Last message repeated 1 times
[tcp @ 0x55efbe503280] Connection to tcp://privateurl.com:8443 failed (Host is unreachable), trying next address
    Last message repeated 1 times
[tls @ 0x55ba15827580] The TLS connection was non-properly terminated.
...

O mesmo vale para o VLC. No windows eu jogo o stream e funciona perfeitamente, sem nenhum erro. Se eu executar o VLC no lado do servidor, o fluxo funcionará intermitentemente para rajadas curtas e o console será spam com erros TLS e No route to host como este:

...
[00007fec88000ef0] main tls client error: TLS session handshake error
[00007fec88000ef0] main tls client error: connection error: No route to host
[00007fec88000ef0] gnutls tls client error: TLS handshake error: Error in the push function.
[00007fec88000ef0] main tls client error: TLS session handshake error
[00007fec88000ef0] main tls client error: connection error: No route to host
[00007fec88000ef0] gnutls tls client error: TLS handshake error: Error in the push function.
[00007fec88000ef0] main tls client error: TLS session handshake error
[00007fec88000ef0] main tls client error: connection error: No route to host
...

Tentei usar traceroute, tcptraceroute, pingar para o privateurl.com e sua porta, e por mais que eu tente dar erro usando esses comandos, sempre funciona perfeitamente.

Então, no momento, estou completamente sem ideias de como fazer isso funcionar ou o que experimentar para descobrir o que está causando o problema. Para mim, parece que a pilha TLS no Linux está quebrada ou é um erro FFMPEG, mas não sei por que funciona no Windows, mas não no meu servidor Linux.

Alguém tem uma ideia?

Tenho um Servidor (Debian) que está servindo algumas pastas via NFS e um Cliente (Debian) que se conecta ao Servidor NFS (Com NFSv4) e monta aquela pasta exportada. Até agora está tudo bem, consigo conectar e modificar o conteúdo das pastas. Mas os usuários estão completamente confusos. Pelo que entendi isso se deve ao NFS usar os UIDs para definir as permissões, e como os UIDs dos usuários do Cliente e do Servidor diferem, então isso acontece, o que ainda é esperado. Mas pelo que entendi, ao habilitar o NFSv4, o IDMAPD deve entrar em ação e usar o nome de usuário em vez dos UIDs. Os usuários existem no servidor e no clientelado, eles apenas têm UIDs diferentes. Mas, por qualquer motivo, o IDMAPD não funciona ou parece não fazer nada.

Então aqui está o que eu fiz até agora:

No lado do servidor:

• nfs-kernel-server instalado
• preencheu /etc/exports com as configurações de exportação adequadas --> /rfolder ip/24(rw,sync,no_subtree_check,no_root_squash)
• e mudou /etc/default/nfs-common para NEED_IDMAPD=yes

Do lado do cliente

• nfs-common instalado
• e mudou /etc/default/nfs-common para NEED_IDMAPD=yes
• e monte a pasta com " mount -t nfs4 ip:/rfolder /media/lfolder "

Reiniciado e reiniciado várias vezes, mas ainda nada. Quando crio no Servidor uma pasta com o usuário A , no Cliente vejo que o dono da pasta é algum usuário X . Quando crio um arquivo do Cliente com o usuário A , no lado do Servidor diz que é de algum usuário Y .

Verifiquei com o HTOP se o processo rpc.idmap está sendo executado no servidor e está de fato. Embora no cliente não pareça estar em execução. Ao tentar iniciar manualmente o serviço no cliente , recebi uma mensagem de erro informando que o IDMAP requer a execução da dependência nfs-kernel-server. Portanto, instalei-o no lado do cliente e agora tenho o processo rpc.idmap em execução no cliente e no servidor . Reiniciei os dois e o problema ainda persiste.

Alguma ideia do que há de errado aqui? Ou como configurar isso corretamente?