Il s'agit d'un routage problème. iptables ne fait pas de routage, mais le routage peut être affecté par les adresses qu'il peut changer et c'est pourquoi iptables est souvent supposé, à tort, faire du routage. En raison de cette iptables ne peut pas être le site solution pour résoudre le problème (mais peut parfois faire partie de cette solution).
En outre, toute tentative d'altérer un réponse paquet utilisant le NAT de Netfilter/iptables est ignoré : le nat n'est déclenchée que pour le premier paquet d'un flux : pas pour une réponse : iptables -t nat -A OUTPUT -p tcp --match multiport --sports 8443,8080 -j DNAT --to 172.24.248.201 ne correspondront jamais. Et s'il était possible de les faire correspondre, cela ne fonctionnerait pas, car la destination de la réponse doit être la source de la requête initiale vue par le vrai serveur : l'adresse IP réelle du client distant, et non le L3B.
Voici une méthode simple pour le faire correctement sur le serveur réel : avec routage politique .
Dans ce problème spécifique et cette réponse, je vais supposer que Noyau Linux >= 4.17 pour "Extends fib rule match support to include sport, dport and ip proto match", ce qui évite une utilisation complexe de iptables pour marquer les paquets (mais qui nécessiterait de toute façon un routage par politique).
Il faut s'assurer que les ports dédiés du serveur réel ne peuvent pas chevaucher la plage de ports dynamiques du serveur réel (utilisée lorsque le serveur est un client, comme pour les requêtes DNS ou la mise à niveau du système) :
# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
Assurez-vous que le port inférieur est supérieur au port le plus élevé du serveur réel utilisé pour un service. Ici : 32768 > 8443 est suffisant.
Ajouter une table de routage pour le trafic spécifique destiné à utiliser le L3 LB comme passerelle. La table 248201 est une valeur choisie arbitrairement. Je suppose que l'interface du serveur réel s'appelle eth0 veuillez vous adapter :
ip route add default via 172.24.248.201 dev eth0 table 248201
Ajoutez les sélecteurs : un par plage de ports. Il peut s'agir d'une seule grande plage (tant qu'il n'y a pas d'interaction avec les ports dynamiques, cela n'a pas d'importance) ou de X règles pour X ports distincts. Pour une seule gamme :
ip rule add iif lo ipproto tcp sport 8000-8443 lookup 248201
donde iif lo est la syntaxe spéciale pour le trafic sortant initié localement et n'est pas vraiment lié à l'interface utilisateur. lo interface.
Maintenant, tout le trafic de retour prévu sera acheminé en utilisant le L3 LB comme passerelle. Tout autre trafic utilisera la passerelle par défaut habituelle si nécessaire.
Je ne pense pas que SRPF devrait être un problème si elle est activée, à moins que la passerelle par défaut habituelle du serveur utilise une autre interface. Si cela devait être un problème, il peut être réglé sur le mode Loose à la place.
À ne faire que si cela ne fonctionne pas sans (et même dans ce cas, eth0 peut suffire au lieu de tous ci-dessous) :
sysctl -w net.ipv4.conf.all.rp_filter=2
