Routage entre 2 FAI [iptables]
Le
Richard Baret
Bonjour à tous
Voici ma config actuelle :
je possède actuellement 2 accès internet, le premier est une offre fibr=
e à débit symétrique de chez Orange, le second est un accès ADSL OV=
H. Ces 2 accès viennent chacun avec leur box respective.
Physiquement ca donne ça :
[fixed]
192.168.0.1 192.1=
68.0.253 192.168.3.1
- ip dynamique -|Livebox|=
-- --Serveur=
HTTP
/ =
\ 192.168.3.253 /
INTERNET =
Passerelle Debian
\ =
/ \
-- 178.x.x.x -|Modem OVH|-=
-- --Serveur=
DNS
192.168.1.254 192.1=
68.1.253 192.168.3.2
[/fixed]
La problématique est la suivante :
[*] L'accès ADSL ne sert qu'à résoudre les requêtes DNS (et les tra=
nsferts de zone) qui lui parviennent et le serveur DNS doit répondre via =
la passerelle OVH
[*] L'accès fibre sert à tout le reste du trafic entrant et sortant
[*] La passerelle Debian a iptables d'installé et de configuré pour tou=
t ce qui est port forwarding mais pas pour le load balancing entre les 2 li=
gnes ADSL (tout le trafic sortant veut absolument sortir par la route par d=
éfaut qui se trouve en premier dans la table de routage de la machine d'o=
ù problème pour les retours vers le net à des connexions entrantes)
Pourriez-vous m'aider à configurer la ou les tables de routage de ma mach=
ine pour que seul le trafic DNS passe par la ligne ADSL (requêtes entrant=
es, réponse aux requêtes entrantes et au pire requêtes DNS sortantes =
pour les forwarders de mon serveur DNS) et pour que tout ce qui est trafic =
entrant sur la ligne fibre (donc à destination du serveur HTTP/FTP etc) r=
essorte par cette même ligne fibre
J'ai trouvé un tuto qu'a pas l'air trop mal, mais qui marche avec des ip =
publiques (machine passerelle attaquée en direct par le FAI) et je pense =
que le SNAT va pas marcher comme indiqué, si ça peut vous aider :
http://linux-ip.net/html/adv-multi-internet.html
Voici ma config actuelle :
je possède actuellement 2 accès internet, le premier est une offre fibr=
e à débit symétrique de chez Orange, le second est un accès ADSL OV=
H. Ces 2 accès viennent chacun avec leur box respective.
Physiquement ca donne ça :
[fixed]
192.168.0.1 192.1=
68.0.253 192.168.3.1
- ip dynamique -|Livebox|=
-- --Serveur=
HTTP
/ =
\ 192.168.3.253 /
INTERNET =
Passerelle Debian
\ =
/ \
-- 178.x.x.x -|Modem OVH|-=
-- --Serveur=
DNS
192.168.1.254 192.1=
68.1.253 192.168.3.2
[/fixed]
La problématique est la suivante :
[*] L'accès ADSL ne sert qu'à résoudre les requêtes DNS (et les tra=
nsferts de zone) qui lui parviennent et le serveur DNS doit répondre via =
la passerelle OVH
[*] L'accès fibre sert à tout le reste du trafic entrant et sortant
[*] La passerelle Debian a iptables d'installé et de configuré pour tou=
t ce qui est port forwarding mais pas pour le load balancing entre les 2 li=
gnes ADSL (tout le trafic sortant veut absolument sortir par la route par d=
éfaut qui se trouve en premier dans la table de routage de la machine d'o=
ù problème pour les retours vers le net à des connexions entrantes)
Pourriez-vous m'aider à configurer la ou les tables de routage de ma mach=
ine pour que seul le trafic DNS passe par la ligne ADSL (requêtes entrant=
es, réponse aux requêtes entrantes et au pire requêtes DNS sortantes =
pour les forwarders de mon serveur DNS) et pour que tout ce qui est trafic =
entrant sur la ligne fibre (donc à destination du serveur HTTP/FTP etc) r=
essorte par cette même ligne fibre
J'ai trouvé un tuto qu'a pas l'air trop mal, mais qui marche avec des ip =
publiques (machine passerelle attaquée en direct par le FAI) et je pense =
que le SNAT va pas marcher comme indiqué, si ça peut vous aider :
http://linux-ip.net/html/adv-multi-internet.html

Poser une question


Si tu ne tiens pas à rester sous debian et à tout faire à la main,
regarde du côté de pfsense (www.pfsense.org), une distrib spécialisée
basée sur FreeBSD où tu fais ça les doigts dans le nez...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Richard Baret a écrit :
Pas facile à lire à cause des lignes beaucoup trop longues qui sont
coupées. Ce problème de longueur de lignes concerne d'ailleurs
l'ensemble du message.
Ce qui suit suppose que la route par défaut est par la livebox.
D'abord, on va remplir une table de routage alternative avec une route
par défaut par OVH. Le numéro de table est choisi arbitrairement.
# sous-réseau de la livebox
ip route add 192.168.0.0/24 dev $if_livebox table 99
# sous-réseau du modem OVH
ip route add 192.168.1.0/24 dev $if_ovh table 99
# sous-réseau local
ip route add 192.168.3.0/24 dev $if_lan table 99
# route par défaut
ip route add 192.168.0.0/24 dev $if_ovh via 192.168.1.254 table 99
Cette table est identique à la table principale à l'exception de la
route par défaut.
Ensuite, on va créer des règles de routages pour les situations où les
paquets doivent être routés selon la table de routage alternative.
# paquets dont l'adresse source est celle de l'interface connectée au
# modem OVH
ip rule add from 192.168.1.253 lookup 99
# paquets marqués par iptables
ip rule add fwmark 0x1 lookup 99
Enfin, on va créer les règles iptables pour marquer les paquets qui
doivent être routés selon la table de routage alternative.
# paquets de requête DNS du serveur DNS reçus par l'interface LAN
# on peut être moins restrictif en supprimant le critère adresse source
iptables -t mangle -A PREROUTING -i $if_lan -s 192.168.3.2
-p udp --dport 53 -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -i $if_lan -s 192.168.3.2
-p tcp --dport 53 -j MARK --set-mark 0x1
# paquets de réponse à une connexion reçue par OVH
iptables -A PREROUTING -i $if_ovh -j CONNMARK --set-mark 0x1
iptables -t mangle -A PREROUTING -i $if_lan -j CONNMARK --restore-mark
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
Bien sûr il ne faut pas oublier les règles de NAT source afin que les
paquets sortent vers les modems avec la bonne adresse source.
iptables -t nat -A POSTROUTING -o $if_livebox -j SNAT --to 192.168.0.253
iptables -t nat -A POSTROUTING -o $if_ovh -j SNAT --to 192.168.1.253
Une fois les principes assimilés, cela devrait pouvoir être adapté à
chaque situation particulière sans trop de difficulté.
J'ai oublié -t mangle.
Aussi, il peut être nécessaire de désactiver rp_filter sur l'interface
qui n'a pas la route par défaut.
sysctl -w net.ipv4.conf.$if_ovh.rp_filter=0
Avec un noyau récent il faut aussi
sysctl -w net.ipv4.conf.all.rp_filter=0
car la combinaison entre les deux a été modifié de ET logique à MAX.