Pivert's Blog

Reading Time: 4 minutes

Une fois qu’on a compris la configuration de base de Shorewall, il est très facile d’y ajouter des interfaces, et de l’utiliser en Firewall-Router.
C’est la configuration nécessaire avant de pouvoir passer à la gestion du trafic avec le QoS et le Traffic Shaping au chapitre suivant.

Voici le second d’une série de 6 articles :

1. Shorewall – Configuration de base en quelques minutes
2. Shorewall – Routeur internet
3. Shorewall – QoS & Traffic shaping pour améliorer les performances réseau
4. Shorewall – Configurations avancées
5. Shorewall – En entreprise : Haute disponibilité, sauvegarde & restauration
6. Shorewall – En entreprise : Traçabilité, documentation des règles, revues d’audit, journalisation

Dans cet exemple, le routeur Shorewall est connecté à un switch avec plusieurs VLANS par un lien Gigabit. Il faut donc :

1. Configurer les nouvelles interfaces au niveau de l’OS.
2. Vérifier que « IP_FORWARDING=Yes » se trouve dans le shorewall.conf (L’IP Forwarding est activé par défaut)
3. Suivre le workflow de configuration de Shorewall :
   1. Nommer les zones : /etc/shorewall/zones
   2. Lier les interfaces réseau à leur zone : /etc/shorewall/interfaces
   3. Dégrossir avec les règles de base entre zones : /etc/shorewall/policy
   4. Affiner avec les règles spécifiques : /etc/shorewall/rules

Configuration des interfaces

C’est maintenant netplan qui est utilisé pour la configuration réseau sous Ubuntu entre autre. Netplan s’intègre à systemd-networkd et au NetworkManager. On peut également le configurer via les fichiers /etc/netplan/*.yaml.

Voici un exemple de configuration avec plusieurs interfaces virtuelles utilisant un lien unique vers un switch, et du vlan tagging. La seule interface réelle est ens18.

network:
    version: 2
    ethernets:
        ens18:
            addresses: [ "192.168.178.12/24" ]
            mtu: 1492
    vlans:
      vlan10:
        id: 10
        link: ens18
        addresses: [ "192.168.10.2/24" ]
        routes:
          - to: 192.168.11.0/24
            via: 192.168.10.40
            metric: 100
          - to: 192.168.220.0/24
            via: 192.168.10.40
            metric: 100


      vlan66:
        id: 66
        link: ens18
        addresses: [ "192.168.66.2/24" ]

      vlan67:
        id: 67
        link: ens18
        addresses: [ "192.168.232.182/26" ]

      internet:
        id: 130
        link: ens18
        addresses: [ "192.168.130.12/24" ]
        mtu: 1492
        nameservers:
            addresses:
            - 9.9.9.9
        routes:
          - { to: default, via: 192.168.130.1 }
          # Make sure afraid.org is only updating IP from direct interface
          - to: 50.23.197.94/31
            via: 192.168.130.1
            metric: 100

      vlan232:
        id: 232
        link: ens18
        addresses: [ "192.168.232.42/25" ]

Comme vous le voyez, la configuration de netplan en yaml est simple et lisible. Pour chaque interface, on peut y ajouter du VLAN tagging, des routes, des adresses, des commentaires…

Le Maximum Transfer Unit

Notez que le MTU de la ligne Internet a été réduit à 1492 (au lieu de 1500). C’est souvent le cas quand internet est fourni par une encapsulation PPP ayant besoin de 8 bytes d’entêtes. Typique des connexions DSL. Ce n’est pas nécessaire, mais peut éviter que le modem ne doive fragmenter les paquets avant de les encapsuler en PPP. Vous pouvez vérifier votre MTU:

root@burns2:/etc/shorewall# ping -M do -s 1500 9.9.9.9 -c1
PING 9.9.9.9 (9.9.9.9) 1500(1528) bytes of data.
ping: local error: message too long, mtu=1492

--- 9.9.9.9 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Ici, on ping Quad9 (9.9.9.9) avec un packet de taille 1500, et on interdit la fragmentation du packet (-M do). On reçoit donc en retour l’ICMP “Message too long”, avec le MTU à utiliser. Mais pour faire passer le paquet, il faudra descendre bien en dessous, car le MTU s’applique à la taille packet ICMP, alors que le -s (size) définit la taille des data encapsulées dans le paquet ICMP.

Activation de la configuration réseau

Une fois le fichier yaml de configuration mis à jour ou créé dans /etc/netplan/, il faut activer la nouvelle configuration :

netplan try

Vous aurez 120s pour accepter la nouvelle configuration.

Configuration de Shorewall

Répétez les 4 étapes de configurations telles que décrites dans le premier article.

En considérant que votre réseau local est dans la zone « loc » et que vous avez une seule « dmz », vous pouvez laisser le fichier rules et commencer avec un /etc/shorewall/policy simple :

###############################################################################
#SOURCE         DEST            POLICY          LOG             LIMIT:BURST
#                                               LEVEL
fw              all             ACCEPT
loc             all             ACCEPT
dmz             net             ACCEPT
dmz             all             REJECT          info
all             all             DROP
#LAST LINE -- DO NOT REMOVE

Configuration du NAT

Si vous utilisez Shorewall pour partager une connexion internet et que vous désirez qu’il prenne en charge le NAT, il faut le définir dans le fichier /etc/shorewall/snat. Exemple:

#ACTION         SOURCE             DEST            PROTO   PORT   IPSEC  MARK   USER    SWITCH  ORIGDEST   PROBABILITY
#
MASQUERADE      192.168.0.0/16     internet

Remarques:

• internet est le nom de l’interface qui est connectée au modem. (c.f. configuration de netplan)
• Vous pouvez cascader plusieurs NAT, ce n’est pas un problème. Par exemple, si votre modem fait déjà du NAT, vous pouvez également faire du NAT au niveau du routeur Shorewall. Le seul intérêt est de ne pas avoir à définir toutes les routes vers le réseau interne sur le modem.
• Attention, on parle bien du fichier /etc/shorewall/snat et non du fichier /etc/shorewall/nat qui est utilisé pour d’autres NAT.

Fonctionnement : le MASQUERADE est un double NAT :

• SNAT (Source NAT) pour les paquets sortants avec l’IP de l’interface « internet », masquant l’IP du host qui a envoyé le paquet derrière le routeur.
• Le connection tracking permet d’appliquer le DNAT (Destination NAT) correspondant pour les paquets en retours.

Tests et vérifications

• Vérifiez que vous pouvez vous connecter à internet en traversant le firewall avec Shorewall active ( shorewall status )
• Utilisez tcpdump, entre autre sur l’interface de sortie :
  tcpdump -pni internet
• Vérifiez les logs
  tail -f /var/log/syslog -n 10000 | grep -E 'REJECT|DROP'
• N’hésitez pas à ajouter temporairement le loglevel info sur la dernière ligne (DROP) du fichier /etc/shorewall/policy.

Conclusion

Vous devriez à présent avoir les interfaces et Shorewall de configuré pour une utilisation en routeur internet avec NAT (Masquerading).

N’hésitez pas à commenter si certains points ne sont pas clairs.