Zonas Shorewall para os dois caminhos de pacotes do OpenVPN
Separe o transporte OpenVPN cifrado do tráfego de cliente decifrado, dê ao túnel a sua própria zona e permita apenas o serviço de que o cliente precisa.
Dois fluxos de pacotes atravessam um gateway Shorewall que termina o OpenVPN, e apenas um deles é cifrado. O primeiro é o transporte do cliente até o ouvinte VPN na interface voltada para a internet. O segundo é o pedido decifrado que sai da interface do túnel para um servidor de escritório ou um serviço no gateway. Mapeie os dois antes de editar a política, porque uma regra que satisfaz o primeiro não faz nada pelo segundo.
Desenhe os dois fluxos antes de editar a política
Escreva os fluxos como linhas com origem, destino, protocolo e porta. No caminho externo, a origem é o endereço público do cliente e o destino é a porta de escuta do gateway; o Shorewall trata isso como tráfego da internet para a firewall. No caminho interno, a origem é o intervalo de endereços do túnel e o destino é o serviço aprovado. As duas linhas têm proprietários diferentes mesmo quando um único administrador mantém as duas.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
Acrescente uma linha apenas se o pedido terminar no próprio gateway, como o acesso ao resolver ou à administração. Um serviço no host segue a política de entrada do host, não o caminho encaminhado. Misturar os dois é como uma regra estreita de túnel acaba expondo uma interface de administração.
Atribua a zona do túnel e o âmbito da interface
A zona do viajante é declarada em /etc/shorewall/zones, a interface do túnel é associada em /etc/shorewall/interfaces e a ligação externa é descrita em /etc/shorewall/tunnels. Ajuste-se à sintaxe da versão instalada, porque a ordem das colunas e os nomes das opções mudaram entre versões principais. A porta de exemplo do guia não é motivo para permitir uma porta diferente daquela em que o daemon realmente escuta. TCP e UDP não são intercambiáveis só porque os números coincidem.
O guia agrupa as interfaces com tun+. Num host com mais de um túnel, esse curinga pode colocar uma segunda VPN de nível de confiança diferente na mesma zona. Reveja o âmbito face às interfaces que existem realmente e mantenha a nomenclatura sob o ciclo de vida do gestor de ligações em vez de editar os nomes das interfaces à mão.
O guia histórico contém exemplos de configuração do OpenVPN muito mais antigos, e os seus conselhos criptográficos não devem ser copiados para uma implantação atual. Empreste antes o modelo de zonas e fluxos. Tire a base criptográfica da política OpenVPN mantida no gateway.
Permita apenas o caminho que classificou
Uma aceitação ampla da zona VPN para a LAN é um esquema inicial, não uma política terminada. Escreva a origem de cliente permitida, o endereço real do serviço, o protocolo e a porta. Depois leia as regras acima e o valor predefinido da zona, porque uma adição estreita não anula uma permissão ampla que já coincide. O tráfego para o host do gateway é uma relação separada do tráfego encaminhado através dele.
O tráfego entre clientes precisa da sua própria decisão. O client-to-client do OpenVPN e o routeback do Shorewall afetam ambos se os clientes conseguem alcançar-se, e nenhum deles deve ser ativado só para fazer funcionar uma aplicação da LAN. Decida onde o isolamento é imposto antes de o testar.
Mantenha o caminho de resposta no mesmo plano. O serviço ou o seu router tem de saber como devolver o tráfego ao intervalo do túnel, ou o desenho tem de traduzir a origem de forma deliberada e dentro do âmbito previsto.
Valide e depois prove os dois caminhos
Valide a configuração antes de reiniciar o que quer que seja e mantenha aberta uma sessão administrativa independente caso a nova política esteja errada.
shorewall checkDepois de uma verificação limpa, aplique a configuração e releia o que o Shorewall carregou. Estas leituras descrevem a política em execução e não o que um ficheiro parece dizer.
shorewall show zones
ip route get 192.168.10.20Teste um pedido permitido novo e um pedido negado de propósito a partir do mesmo cliente. Um aperto de mão OpenVPN bem-sucedido só prova a troca externa; o serviço permitido e o recurso negado provam a política interna que pretendia. Depois reconecte o cliente e repita, porque o nome e o endereço da interface do túnel podem mudar entre sessões. Se o resultado diferir, corrija o âmbito da zona em vez de alargar a regra.