Deixar um cliente OpenVPN ligar-se por SSH a outro sem abrir o pool

Um cliente precisa de chegar ao serviço SSH de outro cliente, e o resto do pool deve continuar tão isolado como hoje. O interruptor tentador é o client-to-client, que ativa o acesso entre pares para todos de uma vez e entrega a decisão ao OpenVPN em vez do kernel. Uma resposta mais estreita mantém esse interruptor desligado e deixa o encaminhamento e a firewall do próprio servidor transportar exatamente um fluxo.

O mecanismo importa mais do que o texto da regra, porque as duas abordagens colocam o pacote em sítios diferentes. Saber qual escolheste explica tanto a regra que parece não fazer nada como o par que se liga sem ela.

Onde o client-to-client move o pacote

Com o client-to-client ativo, o servidor reencaminha um pacote de par internamente em vez de o enviar de volta pelo dispositivo de túnel, pelo que o pacote nunca chega ao caminho de encaminhamento do kernel. Isso é cómodo e também significa que a tua firewall nunca vê o fluxo que devia policiar. Deixa a opção desligada e o servidor encaminha o pacote de volta pela mesma interface, o que o coloca à frente do netfilter. A mesma interface à entrada, a mesma à saída, e a cadeia FORWARD fica com o voto.

A troca é explícita: ganhas um ponto de política e assumes o trabalho de encaminhamento e routing que o atalho fazia por ti. Esse trabalho é pequeno para um único fluxo e cresce com cada exceção que acrescentas. Conta as exceções agora, porque é no conjunto de regras que a política entre pares vive de facto.

O caminho que um pacote de par realmente percorre

Assume um serviço Linux Community OpenVPN 2.6, processamento TUN em espaço de utilizador em vez de DCO, topologia de sub-rede, tun0 e um pool de 10.44.0.0/24 com o cliente A em 10.44.0.21 e o cliente B em 10.44.0.37. Com topologia de sub-rede, o endereço e a máscara que o A recebeu já cobrem o pool, pelo que o A envia o pacote para o dispositivo de túnel sem precisar de uma rota empurrada extra. Verifica a rota efetiva no A em vez de assumires uma.

No servidor, o pacote chega endereçado ao B, que não é um endereço local, pelo que é encaminhado. O encaminhamento IPv4 tem de estar ativo para que isso aconteça, e a procura de rota tem de enviar o pacote de volta por tun0. A firewall vê, portanto, um fluxo encaminhado com a mesma interface dos dois lados, e é esse o detalhe que a maioria dos conjuntos de regras falha. Aqui não é preciso tradução de origem, e é por manteres o endereço do A intacto que o B pode aplicar a sua própria regra baseada na origem.

Duas regras no servidor, por esta ordem

Três regras transportam toda a autorização: o encaminhamento, a exceção do par e um descarte predefinido para o par de túnel. A regra de aceitação nomeia o par e o serviço, pelo que a autorização sobrevive a um pool que cresce. Coloca-a antes de qualquer negação geral do tráfego túnel-a-túnel, porque ganha a primeira correspondência:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Esses comandos são ilustrativos e pertencem ao mecanismo que o teu anfitrião usar para persistir regras; uma inserção em tempo de execução desaparece no arranque seguinte. É a regra com estado que permite às respostas do B e ao aperto de mão TCP voltar sem uma segunda aceitação espelhada.

Verifica os contadores depois, não a lista de regras, porque uma regra que nunca corresponde é idêntica a uma que funciona. Se os contadores ficarem a zero, o pacote não está a seguir o caminho que pensas.

O que o B ainda tem de permitir

O B corre o serviço SSH, por isso é o B que decide se algo escuta no endereço do túnel e se a firewall do próprio anfitrião aceita a origem. Uma permissão de rede no servidor não é permissão para nenhuma conta no B, e a verificação da chave do anfitrião e a autenticação de utilizador continuam a aplicar-se como de qualquer outro sítio.

Testa primeiro o caso positivo: uma nova ligação SSH do A ao endereço do túnel do B, aceite com a chave de anfitrião esperada. Depois testa outro par ou outra porta e confirma que é recusada, porque uma autorização que permite tudo em silêncio é indistinguível de uma que funciona até ser importante. As duas metades desse teste são necessárias, e a segunda é a que as pessoas saltam.

Regista os endereços atribuídos, as rotas efetivas nos dois clientes e as regras exatas no servidor e no B. Um ping bem-sucedido ao gateway ou uma porta aberta no servidor não prova nada disto, já que ambos podem ser verdade enquanto o encaminhamento entre pares continua bloqueado. Escreve esses números com o túnel levantado, porque o endereço que um cliente recebe depois de se voltar a ligar pode ser outro.