2 LAN ->2 SQUID-> 2 gw : forcer squid a util une gw precise

megs · Février 20, 2016, 10:27pm

bijours,
Linux proxi-lpa 2.6.26-2-686 #1 SMP Sun Jun 21 04:57:38 UTC 2009 i686 GNU/Linux
Je precise que je ne veux pas de load balancing. ca je sais faire…

Un même serveur est destiné a faire proxy sur deux accès web indépendants resevé à un seul LAN.

…voir suite (Edit)

MERCI d’avance.

fran.b · Février 20, 2016, 10:27pm

Tu marques les paquets et tu les routes en fonction de la marque, il y a un fil là dessus…

megs · Février 20, 2016, 10:29pm

alors, voici ou j’en suis:
rt_tables

...
200 ADMIN
201 PEDA

ip rule:

0:      from all lookup local
9997:   from all fwmark 0x1 lookup ADMIN
9998:   from all fwmark 0x2 lookup PEDA
9999:   from 10.0.0.2 lookup ADMIN
9999:   from 10.0.1.2 lookup PEDA
10000:  from all lookup main
15000:  from all lookup default

iptables

Exécuter la chaîne MARK 0x1	Si la source est 172.16.1.0/24 et la destination n'est pas 172.16.1.1 		
Exécuter la chaîne MARK 0x2	Si la source est 172.16.2.0/24 et la destination n'est pas 172.16.2.1

ip route

10.0.0.0/30 dev eth1  proto kernel  scope link  src 10.0.0.2
172.16.2.0/24 dev eth6  proto kernel  scope link  src 172.16.2.1
172.16.3.0/24 dev eth7  proto kernel  scope link  src 172.16.3.1
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.87
172.16.1.0/24 dev eth5  proto kernel  scope link  src 172.16.1.1
172.16.0.0/16 dev eth4  proto kernel  scope link  src 172.16.0.1
default via 10.0.0.1 dev eth1

squid1.conf

acl clients src 172.16.1.0
tcp_outgoing_address 10.0.0.1 clients

et squid2.conf

acl clients src 172.16.2.0
tcp_outgoing_address 10.0.1.0 clients

avec ca, j’ai mes client sur eth5 et eth6 qui consulte le net sans soucis… et c’est problematique… … bha oui surtout quand squid n’est pas actif pour le reseau eth6… et que ca marche quand même.
(c’est un proxy transparent avec reroutage vers le port squid pour tout ce qui est 80.)

1/ quelqu’un saurrait-il comment changer de table pour lister les routes de ADMIN par exemple ? ok trouvé =

ip route list table ADMIN merci dric64 g vu trops tard
2/ comment faire du routage basé sur l’ip source en imposant une passerelle par defaut ?

3/ pourquoi ce vilain il me répond invalid arguement à ca:
ip route add 10.0.0.0/30 dev eth1 src 10.0.[size=150]1[/size].2 table ADMIN
->voila ce qui arrive quand on saute le repas de midi…

4/ comment on ajoute une table si ce fichu truc nous repond:

ip route add default via 10.0.0.1 table ADMIN
ip route add default via 10.0.1.1 table PEDA
RTNETLINK answers: No such process
ou
ip route list PEDA
Error: an inet prefix is expected rather than “PEDA”.
-> Vu faut que le link soit UP…

dric64 · Février 20, 2016, 10:29pm

Pour lister les routes de la tables ADMIN :
ip route show table ADMIN

Edit : ah oui tien, ip route list ca marche aussi

megs · Février 20, 2016, 10:29pm

et je termine par interface:

#//////////////////////////////////////////////
#  ETH0  
#//////////////////////////////////////////////
iface eth0 inet static
	address 192.168.1.87
	netmask 255.255.255.0
	broadcast 192.168.1.255
	network 192.168.1.0
	# gateway 192.168.1.4
	# COMMANDS  ___________________________
	pre-up echo 1 > /proc/sys/net/ipv4/ip_forward

#//////////////////////////////////////////////
#  ETH1 - table ADMIN 
#//////////////////////////////////////////////
iface eth1 inet static
	address 10.0.0.2
	netmask 255.255.255.252
	broadcast 10.0.0.3
	network 10.0.0.0
# COMMANDS  ___________________________
post-up ip route add 10.0.0.0/30 dev eth1 src 10.0.0.2 table ADMIN
      post-up ip route add default via 10.0.0.1 table ADMIN
	post-up ip rule add from 10.0.0.2 table ADMIN
	post-up ip rule add fwmark 1 table ADMIN
 	post-down ip rule del from 10.0.0.2 table ADMIN

#//////////////////////////////////////////////
#  ETH2 - table PEDA  
#//////////////////////////////////////////////
iface eth2 inet static
	address 10.0.1.2
	netmask 255.255.255.252
	broadcast 10.0.1.3
	network 10.0.1.0
	# COMMANDS  ___________________________
	post-up ip route add 10.0.1.0/30 dev eth2 src 10.0.1.2 table PEDA
        post-up ip route add default via 10.0.1.1 table PEDA
	post-up ip rule add from 10.0.1.2 table PEDA
	post-up ip rule add fwmark 2 table PEDA
 	post-down ip rule del from 10.0.1.2 table PEDA
...

#///////////////////////////////////////////////
# GLOBAL COMMANDS /ETH7
#///////////////////////////////////////////////
       post-up ip route add 172.16.1.0/24 dev eth5 table ADMIN
       post-up ip route add 172.16.3.0/24 dev eth7 table ADMIN
       post-up ip route add 172.16.2.0/24 dev eth6 table PEDA

dric64 · Février 20, 2016, 10:29pm

Edit : j’ai rien dit, au temps pour moi
Par contre, t’a oublié de lui donner la route qu’il doit prendre, je pense :
ip route add 10.0.0.0/30 via adresse_Gateway dev eth1 src 10.0.1.2 table ADMIN

J’avais eu cette erreur quand je m’étais gourré dans l’adresse de la passerelle. Je dirais qu’il n’arrive pas à joindre la passerelle que tu lui indiques, mais sans certidude. Peut être dans ton cas, car tu ne lui spécifie pas l’interface (le dev ethX ne figure pas dans ta ligne)
Je viens de faire des tests : il faut que la route vers ton réseau 10.0.0.0 figure dans la table main. vérifie si elle y est (avec ip route show table main), si elle n’y est pas, c’est surement à cause de ca que t’a cette erreur (je viens de tester en créant des routes bidons sur une table alternative, il ne les accepte que si je lui donne la route vers la gateway en question dans la table main, sinon, j’ai la même erreur que toi)

megs · Février 20, 2016, 10:29pm

ok y a bon—

#~/>ip route list table main
10.0.0.0/30 dev eth1  proto kernel  scope link  src 10.0.0.2
10.0.1.0/30 dev eth2  proto kernel  scope link  src 10.0.1.2
172.16.2.0/24 dev eth6  proto kernel  scope link  src 172.16.2.1
172.16.3.0/24 dev eth7  proto kernel  scope link  src 172.16.3.1
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.87
172.16.1.0/24 dev eth5  proto kernel  scope link  src 172.16.1.1
172.16.0.0/16 dev eth4  proto kernel  scope link  src 172.16.0.1
#~/>ip route list table ADMIN
10.0.0.0/30 dev eth1  scope link  src 10.0.0.2
172.16.3.0/24 dev eth7  scope link
172.16.1.0/24 dev eth5  scope link
default via 10.0.0.1 dev eth1
#~/>ip route list table PEDA
10.0.1.0/30 dev eth2  scope link  src 10.0.1.2
172.16.2.0/24 dev eth6  scope link
default via 10.0.1.1 dev eth2
#~/>ip rule
0:      from all lookup local
32762:  from all fwmark 0x2 lookup PEDA
32763:  from 10.0.1.2 lookup PEDA
32764:  from all fwmark 0x1 lookup ADMIN
32765:  from 10.0.0.2 lookup ADMIN
32766:  from all lookup main
32767:  from all lookup default

vala, ya des routes par defaut dans mes tables secondaires.
et les règles sont sanglantes. .

et pourtant…

10.0.0.1---10.0.0.2/ADMIN+FW-SQUID1:8080/172.16.1.1---172.16.1.254
................................|icp link
10.0.1.1---10.0.1.2/PEDA+FW-SQUID2:8081/172.16.2.1---172.16.2.254

172.16.1.254… n’a pas le net… pkoi ???

avec
ip rule add from all table ADMIN
ip rule add from all table PEDA

ca marche bien … so ??? c ptet un rule qui manque mais je ne vois pas lequel ? y a un route ou un rule qui pêche keke part… pasque le client net 172.16.1.254 ne ping pas 10.0.0.1. Hors, en local sur la passerelle ca ping bien vers partout (sauf vers net vu qu’y a pas de default route dans main.).
mais logiquement vu qu’il y a un default dans chaque table secondaire, et comme le markage, et les lois impose l’arrivé du trafic du 172.16.1.0 par exemple dans la tables ADMIN, tout le traffic sortant ne devrais il pas sortir correctement et revenir ?

pouvez vous m’expliqué ce que apparement je n’ai pas saisi ?

Merci d’avance…

dric64 · Février 20, 2016, 10:29pm

C’est quoi toutes ces interfaces : eth4, 5, 6, 7… qu’on voit dans les tables ?

megs · Février 20, 2016, 10:29pm

2x4 ports ethernet Gigabits agrrégable sur 2 cartes différentes. donc eth0 à eth7… mais ils n’entrent pas dans le chmilblik proxi. il seront réservé à autre chose.

autre éléments:
le client .254 ping correctement l’interface 10.0.0.2 du proxy qui n’est pas sur sont réseau originel… mais il ne trouve toujours pas le routeur, apres cet interface ci… pas de ping sur 10.0.0.1.
c bizarre… comme si la redirection de packet navait pas lieu…

il faut marquer comment les fwmark: 0x1 ou 1 ?

RHAAAAAAAAAAAA! CT JUSTE CAAAAAAAAAAAAAAAAAA!!!
encore un beans dû à webmin…

Pour Les marquages de paquet avec le module iptable de webmin:

utilisez le chiffre brut ( --setmark 1 ) 
puis avec ip rule ( 0x1 )... ou inversement
... nimportnawoaks ca!!...

C cool ca marche, a cet instant je ping correctement google, du client 172.16.1.254, alors que la passerelle en local ne sait pas le faire. c’est exactement le résultat voulut…

YYYYYYES ONE STEP DONE

reste un petit détail, qqu’un sait si il existe une option pour bind afin de lui faire ses requêtes via un routeur particulier (style tcp_outgoing_address(comme squid) ?, sans que le route par defaut soit effectif dans la table main ca me permettrait de verifier que squid passe bien via la table ADMIN plutot que par le route de main afin de faire ses requêtes HTTP?

alors, c’est la résolution de nom qui pose probleme maintenant.

dric64 · Février 20, 2016, 10:29pm

c’est typique de webmin alors parce que sur ma petite install (sans webmin), j’ai utilisé des décimaux dans les 2 cas avec succès.
Félicitations