Acheminer un sous-réseau d’agence par la sortie Internet du SonicWall du siège

Les téléphones de l’agence devraient sortir par le siège tandis que les ordinateurs portables de l’agence continuent d’utiliser le WAN local, et la stratégie de routage seule n’y parviendra pas. Une route d’agence peut sélectionner le tunnel, mais la stratégie de tunnel doit accepter le trafic, le siège doit le transmettre et le traduire, et la réponse doit revenir par le même chemin. Ratez l’un de ces trois et le symptôme sera un sous-ensemble de clients qui perdent Internet précisément tant que le tunnel est actif.

Commencez par le sélecteur, pas par la route

La stratégie de routage correspond à une source, donc la source doit être stable avant tout le reste. Placez les appareils choisis dans un groupe d’adresses qu’un administrateur maintient ou, mieux, sur un segment dédié dont l’appartenance suit le rôle de l’appareil. Lorsque la rotation DHCP ordinaire peut déplacer une adresse correspondante vers une autre machine, la stratégie sélectionne silencieusement le mauvais client, et le premier signalement concerne généralement une navigation lente qui est en réalité un détour.

Nommez le groupe d’après la stratégie qu’il sert, et non d’après un étage ou un service, car la règle de routage survivra aux deux. Notez quels appareils s’y trouvent et qui est autorisé à en ajouter un.

Ajoutez la stratégie de l’agence, puis défendez son ordre

Sur le SonicWall de l’agence, une stratégie de route sélectionne le groupe source, nomme les destinations voulues et définit l’interface de tunnel comme passerelle, ce à quoi sert précisément la conception d’interface de tunnel prise en charge. Gardez les règles des destinations locales et privées au-dessus de la règle Internet large, car la première correspondance gagne et un préfixe privé poussé dans le tunnel n’arrive au siège que pour être rejeté. Préservez aussi la route propre du pare-feu vers son homologue VPN, sinon le transport du tunnel suivra la stratégie dont il dépend. Rien de tout cela ne vous oblige à convertir chaque tunnel existant fondé sur une stratégie ; une interface de tunnel est un choix pris en charge parmi plusieurs.

L’ordre est la partie qui change par accident. Quiconque ajoute une exception doit l’insérer au-dessus de la règle large, et quiconque modifie la règle large peut inverser toute la conception d’un seul enregistrement. Écrivez l’ordre prévu à côté de la stratégie et revérifiez-le après les mises à jour du micrologiciel, car le nommage des interfaces et le rendu des stratégies évoluent bien entre les versions.

Terminez le chemin au siège

La stratégie de tunnel du siège doit accepter le trafic que la route de l’agence sélectionne désormais. Un sélecteur inter-bureaux limité au LAN privé du siège n’est pas une autorisation de transporter des destinations publiques arbitraires, donc la stratégie a besoin de la source de l’agence et de la plage de destinations que vous visez réellement. Le siège transmet ensuite ce trafic entrant à son lien Internet selon ses propres règles d’accès, et l’exemple de sortie centrale de SonicWall inclut la traduction de source pour le réseau distant au WAN central. Sans cette traduction, le côté distant voit une adresse privée d’agence et n’a aucune route de retour vers elle.

Les réponses sont l’autre moitié du contrat. Elles doivent revenir par le tunnel ou par la traduction avec état créée pour elles, et le trafic des sites privés peut nécessiter un traitement NAT différent de celui de la sortie publique. Gardez ces règles distinctes, car une règle de traduction large qui masque chaque source interne rend la journalisation et le dépannage ultérieurs bien plus difficiles à lire.

Décidez ce que fait le groupe lorsque le tunnel tombe

Si la sortie centrale est une exigence et non une préférence, revenir au WAN local est un manquement à la conformité même si les utilisateurs restent en ligne. SonicOS documente une route de rejet d’interface de tunnel comme le moyen pris en charge d’empêcher le trafic sélectionné d’emprunter un chemin alternatif non voulu.

Alignez la portée et la priorité de cette route sur la version installée, et testez-la en coupant le tunnel plutôt qu’en faisant confiance à l’étiquette. Un groupe qui ne doit jamais sortir localement devrait échouer fermé, tandis qu’un groupe où la disponibilité compte davantage peut légitimement basculer ; les deux sont des décisions, et aucune ne devrait se produire par défaut.

Vérifiez depuis trois clients, puis revenez proprement en arrière

Un ping vers la passerelle centrale teste la mauvaise chose, car il part du pare-feu et non d’un client sélectionné. Testez plutôt depuis les appareils, et testez-en trois : un appareil sélectionné, un appareil ordinaire qui doit rester local, et un qui dépend de services locaux.

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

Comparez où la requête publique a réellement émergé. Un client sélectionné devrait atteindre Internet par la sortie du siège, et un client ordinaire devrait toujours présenter l’adresse propre de l’agence côté distant ; 203.0.113.10 est une adresse de documentation utilisée comme substitut de la destination qui vous intéresse. Incluez le DNS dans la même passe, car un client qui interroge le résolveur de l’agence peut produire une requête issue du routeur avec une autre source et donc une autre route.

Le retour en arrière, c’est l’ordre de stratégies enregistré plus le groupe d’adresses. Rétablissez l’ordre précédent, retirez le groupe de la stratégie et retestez les deux classes d’appareils. Conservez la configuration exportée avec le journal des modifications, car l’ingénieur suivant doit savoir quelle règle était la large avant que quelqu’un ne la modifie.