Zonas de Shorewall para os dous camiños de paquetes de OpenVPN
Separe o transporte cifrado de OpenVPN do tráfico de cliente descifrado, dea ao túnel a súa propia zona e permita só o servizo que o cliente necesita.
Dous fluxos de paquetes atravesan unha pasarela Shorewall que termina OpenVPN, e só un deles vai cifrado. O primeiro é o transporte do cliente ata o oínte de VPN na interface orientada a internet. O segundo é a petición descifrada que sae da interface do túnel cara a un servidor de oficina ou un servizo na pasarela. Debuxe ambos antes de editar a política, porque unha regra que satisfai o primeiro non fai nada polo segundo.
Debuxe os dous fluxos antes de editar a política
Escriba os fluxos como filas con orixe, destino, protocolo e porto. No camiño exterior, a orixe é o enderezo público do cliente e o destino é o porto do oínte da pasarela; Shorewall trátao como tráfico de internet á devasa. No camiño interior, a orixe é o rango de enderezos do túnel e o destino é o servizo aprobado. As dúas filas teñen propietarios distintos mesmo cando un só administrador mantén ambas.
| 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 |
Engada unha fila só se a petición remata na propia pasarela, como o acceso ao resolutor ou á administración. Un servizo no host segue a política de entrada do host, non o camiño reenviado. Mesturar ambos é como unha regra estreita do túnel acaba expoñendo unha interface de administración.
Asigne a zona do túnel e o alcance da interface
A zona do viaxeiro declárase en /etc/shorewall/zones, a interface do túnel asóciase en /etc/shorewall/interfaces e a conexión exterior descríbese en /etc/shorewall/tunnels. Axústese á sintaxe da versión instalada, porque a orde das columnas e os nomes das opcións cambiaron entre versións principais. O porto de exemplo da guía non é motivo para permitir un porto distinto do que o daemon escoita realmente. TCP e UDP non son intercambiables só porque os números coincidan.
A guía agrupa as interfaces con tun+. Nun host con máis dun túnel, ese comodín pode colocar unha segunda VPN doutro nivel de confianza na mesma zona. Revise o alcance fronte ás interfaces que existen realmente e manteña o nomeado baixo o ciclo de vida do xestor de conexións en lugar de editar os nomes das interfaces á man.
A guía histórica contén mostras de configuración de OpenVPN moito máis antigas, e os seus consellos criptográficos non deben copiarse nunha implantación actual. Tome prestado no seu lugar o modelo de zonas e fluxos. Tome a base criptográfica da política de OpenVPN mantida na pasarela.
Permita só o camiño que clasificou
Unha aceptación ampla da zona VPN á LAN é un esquema inicial, non unha política rematada. Escriba a orixe de cliente permitida, o enderezo real do servizo, o protocolo e o porto. Despois lea as regras que hai por riba e o valor por defecto da zona, porque unha engádega estreita non cancela un permiso amplo que xa coincide. O tráfico cara ao host da pasarela é unha relación distinta do tráfico reenviado a través dela.
O tráfico entre clientes necesita a súa propia decisión. O client-to-client de OpenVPN e o routeback de Shorewall afectan ambos a se os clientes poden alcanzarse, e ningún debería activarse só para que funcione unha aplicación de LAN. Decida onde se aplica o illamento antes de probalo.
Manteña o camiño de resposta no mesmo plan. O servizo ou o seu encamiñador debe saber como devolver o tráfico ao rango do túnel, ou o deseño debe traducir a orixe de forma deliberada e dentro do alcance previsto.
Valide e logo demostre ambos camiños
Valide a configuración antes de reiniciar nada e manteña aberta unha sesión administrativa independente por se a nova política é incorrecta.
shorewall checkTras unha comprobación limpa, aplique a configuración e relea o que Shorewall cargou. Estas lecturas describen a política en execución e non o que un ficheiro parece dicir.
shorewall show zones
ip route get 192.168.10.20Probe unha petición permitida nova e unha petición denegada a propósito desde o mesmo cliente. Unha aperta de mans de OpenVPN correcta só demostra o intercambio exterior; o servizo permitido e o recurso denegado demostran a política interior que pretendía. Despois reconecte o cliente e repita, porque o nome e o enderezo da interface do túnel poden cambiar entre sesións. Se o resultado difire, corrixa o alcance da zona en lugar de ampliar a regra.