Bonjour,
Est-il possible de faire du routage selectif selon une URL avec Iptables ou Nftables?
Merci à toutes et tous
Bonjour,
iptables et nftables peuvent filtrer par rapport à l’adresse IP et je ne sais pas si ces outils gèrent le routage.
Le routage se fait avec les adresses IP de l’entête du paquet, par par son contenu (sinon, c’est trop long).
Je sais pas si ça rentre vraiment dans la catégorie « routage », mais ces outils peuvent faire passer des paquets d’un réseau à un autre, avec DNAT (mais pas en fonction des URL en effet)
Je pense qu’il faut plutôt regarder du côté d’un serveur web / mandataire inverse (Reverse Proxy dans la langue de Will Ferrell), pour « router » (ou plutôt « rediriger ») des connexions selon les URL.
Je suppose que tu parles de HTTP ou HTTPS. Quel est le besoin ?
iptables peut rechercher une chaîne de caractères présente dans un paquet (-m string) et marquer le paquet (-j MARK) ou sa connexion (-j CONNMARK). En HTTP, l’URL (divisée en deux : chemin et requête avec la méthode, nom d’hôte avec l’en-tête Host) est en clair. En HTTPS, la requête HTTP est chiffrée mais le nom d’hôte est en clair dans le ClientHello TLS/SSL si l’extension SNI est utilisée par le client.
Cependant :
- Il n’est pas garanti que les éléments de l’URL soient contenus dans un même segment.
- Les premiers paquets de la connexion émis avant l’envoi de la requête HTTP ou du ClientHello TLS ne peuvent pas être marqués. C’est rédhibitoire si les paquets d’une même connexion ne peuvent pas emprunter indifféremment chaque route.
Indirectement, via le marquage des paquets qui peut ensuite être utilisé comme critère de routage avancé avec ip rule.
« Faire passer des paquets d’un réseau à un autre » est bien une définition du routage (plus précisément de la fonction « routeur ») , ça n’a rien à voir avec le NAT de netfilter.
Au travail il nous arrive de faire une translation de ports avec iptables, pour rendre ponctuellement accessible depuis l’extérieur un service d’un conteneur sur un réseau non routable, du style :
iptables -t nat -A PREROUTING -i <interface publique hôte> -p tcp --dport <port "exotique"> -j DNAT --to <adresse non routable du conteneur>:<port du service voulu>
Si je comprends bien, la différence entre un NAT de ce type et un vrai routeur, c’est que le filtrage ne se fait pas sur les mêmes objets / couches réseau (le NAT sur les ports, le routage sur les adresses) ?
Merci pour ces réponses.
Nous utilisons deux accès vers l’Internet. Un ensemble de trois box en partage avec Pfsense et un accès fibre. Nous filtrons avec -j MARK les flux HTTP et HTTPS vers la connexion fibre plus rapide. Mais filtrée sur certains sites. Donc l’idée est de marquer les paquets vers ses sites et de les renvoyer vers les accès (lents).
je ne comprends pas :
C’est rédhibitoire si les paquets d’une même connexion ne peuvent pas emprunter indifféremment chaque route
Merci
Tu veux dire « non routé depuis l’extérieur » ? Si le réseau cible était réellement non routable (exemple : 127.0.0.0/8), alors ça ne marcherait pas.
Non, ça n’a rien à voir. Le NAT de netfilter ne fait que modifier les adresses et/ou ports source et/ou destination et ne s’occupe pas du routage. Ensuite c’est le routage normal qui s’aplique.
Oui tout à fait.
C’est plus clair pour moi, merci.
Donc le critère de sélection est le nom d’hôte plutôt que l’URL entier, non ?
Vous avez été vilains ?
Un scénario concret sera peut-être plus parlant. Soit une connexion HTTP ou HTTPS.
D’abord, il y a la poignée de main TCP (SYN, SYN+ACK, ACK). Ces paquets ne contiennent pas le nom d’hôte donc la sélection ne peut s’appliquer et ils sont routés vers l’accès internet par défaut. Les routeurs de sortie des deux accès internet font probablement du NAT source/masquerading, donc le routeur applique son adresse IP source aux paquets avant de les renvoyer vers l’extérieur et le serveur cible.
Ensuite arrive le paquet contenant la requête HTTP avec un en-tête Host ou le ClientHello TLS avec une extension SNI qui contient le nom d’hôte. La sélection peut s’appliquer, ce paquet et les suivants sont routés vers l’accès internet alternatif.
C’est là que ça se complique. Plusieurs choses peuvent se produire :
- Si le routeur de l’accès internet alternatif fait du filtrage à état et voit arriver des paquets d’une connexion TCP alors qu’il n’a pas vu passer la poignée de main, il peut les considérer comme invalide et les rejeter.
- Sinon, il leur applique son adresse IP source (masquerading) et les route vers l’extérieur. Le serveur distant voit arriver ces paquets avec une adresse source différente de celle de la poignée de main (qui était celle de la connexion internet par défaut) et les rejette.
En conclusion : attendre l’envoi du nom d’hôte pour sélectionner l’accès internet à utiliser, ce n’est pas très fiable mais surtout c’est trop tard. Une alternative consiste à utiliser l’adresse IP destination comme critère au lieu du nom d’hôte. C’est moins fin car plusieurs sites peuvent partager la même adresse IP, et moins pratique parce la liste d’adresses IP doit être établie et régulièrement mise à jour (car les adresses IP associées à un nom d’hôte peuvent changer dans le temps), on ne peut pas faire de correspondance sur les sous-domaines…
1 J'aime
Sans entrer dans le détail de gestion des paquets, cela s’apparente à une gestion QoS et gestion de proxy.
avec certains proxy, on peut lui faire envoyer les flux sur une passerelle ou une autre, chaque passerelle n’etant rien d’autre qu’un « serveur » backend.
les QoS permettent de gerer les priorité, et depuis quelques temps certains système peuvent aussi gérer les flux.
En 2015, je bossais dans une boites où les connexions de messagerie et internet étaient envoyés vers un lien, et les connexion des applications métiers étaient envoyées vers un autre lien. C’était réalisé avec un UTM Checkpoint à l’époque.
Avec PFsense, il y a peut être matière ici, en utilisant des alias (groupe d’alias) sur tes URLs:
https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html
pour la création d’aliases:
https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html
Un lien de forum sur ta problématique:
Shorewall gère plusieurs providers et des règles de routages en fonction de l’IP, une adresse réseau, ou une interface (source et destination), je l’avais mis en place chez un client mais il y a déjà longtemps. En plus l’interface Webmin de Shorewall est très bien faite.
Sam.
Sauf qu’il a déjà un parefeu avec un pfsense 
c’est sur le pfsense qui gère les connexions qu’il faut faire les routages.
Je ne connais pas pfsense donc je ne sais pas comment il gère les routages et avec quelles interfaces il utilise.
Sam.
pfsense, et son fork opnsense sont des distribution freebsd UTM (Unified Thread Management).
Ca fait parefeu, routeur, proxy, haute disponibilité, ids, load balancing, etc…
Il st capable de faire du routage à partir d’url (i.e.: ww.google.fr par exemple) vers des gateways spécifiques
Bonsoir PascalHambourg,
Sincèrement, je ne cesserais jamais d’être étonné par l’étendu de tes connaissances.
Sérieusement y a t’il des éléments dans ce domaine que tu connais pas ?
En tout cas ce post est très intéressant.
Cordialement
Bonjour,
Merci PascalHambourg, j’avance sur le projet et comme Maveric, je suis étonné par tes connaissances et la capacité à les restituer de façon clair et pratique. Merci encore