SMPFR

j'étais pareil

bon, maintenant, tu interconnecte ton VPS avec le dédié, et faut que tu puisse pinger de ton LAN sans passer par le net.

au boulot, t'as 2h

j'ai du travail moi monsieur

(du coup, je reprends le même fichier qu'@home et je change les ip non? )

presque.
c'est sur le dédié que ça sera le plus complexe.

tu recrée une NET-TO-NET2 (en recopiant l'autre) dans la conf IPSEC avec cette fois l'IP du VPS
coté VPS, tu reprend le même que @home (avec un nouveau réseau)

pour iptables,
@home, t'as rien a faire
sur le dédié, faut rajouter les règles vers le réseau du VPS
sur le VPS, tu reprend le même que @home en changeant par le nouveau réseau

un conseil, ne met pas en démarrage automatique le second tunnel. ya des chances que tu perde la main sur le dédié si tu te vautre (tout ce qui viens de la maison va sur le VPS) du coup, si en auto, pour reprendre la main, ça va être compliqué (alors que la un reboot, et hop, tunnel fermé, et tu retrouve les commandes)

j'ai aucun tunnel auto pour l'instant ^^ et avant de passer le vps, je veux régler le soucis de ssh, car si la même arrive sur le vps ca va pas me plaire ^^

sur le vps, faut que je crée une nouvelle eth aussi non? comme sur le online

pas nécessaire mais moi j'ai préféré le faire.
ça permet de faire écouter tes services sur une interface dédiée plutôt que sur le WAN et de se faire chier a filtrer au firewall après.
la tu bourrine, tu bloque tout le WAN sauf ton tunnel et ssh, et tu laisse tout ouvert sur l'interface virtuelle.

ouaip vais partir la dessus je pense

bon le coup du ssh c'est un mystère!

les vm pinguent le online et inversement, online ping l'interface dmz de ma vm ainsi que celle dans mon lan et d'autres.

main mes vm dans mon lan ne pinguent ni la patte en dmz ni celle dans le lan.

la vm ipsec ping bien le serveur online mais pas le lan

oO

j'avoue que je vois pas le pk du comment

même comportement chez moi, j'avais jamais testé (elle faisait son taf, j'ai pas cherché plus loin)
vais regarder

les routes sont bizarres pour certaines je trouve:

[cpp]Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth1
172.16.35.0 192.168.0.13 255.255.255.0 UG 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
[/cpp]

pk deux fois 192.168.0.0 sur eth1 et eth0?

parce que de base, tu as 2 interfaces qui dans l'absolu ont besoin de joindre ton LAN.
essaie de virer la 6

si je vire la 6 ca veut dire que tout passe par eth1 et donc l'interface dédiée au vpn, pas correct du coup?

j'ai trouvé la ligne qui me permet d'avoir accès au lan:

ip route add 192.168.0.0/24 via 192.168.0.11 dev eth0

mais en faisant ca, je perds le ping vers le vpn....

raaa

si je vire la 6 ca veut dire que tout passe par eth1 et donc l'interface dédiée au vpn, pas correct du coup?

en fait, je voulais dire la 5 !!!

j'ai trouvé la ligne qui me permet d'avoir accès au lan:

ip route add 192.168.0.0/24 via 192.168.0.11 dev eth0

mais en faisant ca, je perds le ping vers le vpn....

raaa

c'est pas un problème de route je pense. plutôt au niveau iptables FORWARD

suis pas sur car quand je fais un traceroute depuis la vm ipsec vers mon lan, ca part par le tunnel

justement, je pense que les règles FORWARD ratissent trop large

j'ai trouvé !!!!

en fait, ça viens de la conf IPSEC de la passerelle (donc la VM dans nos cas.)

dans le ipsec.conf:
rightsubnet=0.0.0.0/0
ça route tout vers le tunnel !
y compris ce qui est destiné au LAN

dans mon cas, c'est ce que je voulais (pouvoir utiliser le VPN pour faire du transit par OVH)
mais du coup, ça ratisse trop large.

je regarde si ya moyen de faire des exclusion .... sans conviction

edit: oui, j'ai toujours qq insomnies, que j'occupe comme je peux.

on s'occupe comme on peut quand c'est comme ca ^^

perso je fais joujoue avec du sas

je regarde si ya moyen de faire des exclusion .... sans conviction

bon bah la réponse est non.
pas moyen de faire des exclusions.
par contre, on peut mettre une infinité de réseaux à router dans l'option rightsubnet=
donc faut prendre papier/crayon et écrire tous les réseaux à router mais sans 192.168.0.0/24
j'ai réfléchi, la liste va être longue.....

autre soluce, qui nécessite des modifs a chaque fois, c'est d'ajouter les réseaux a la main en même temps qu'on les ajoute au routage (dans l'option 249 du DHCP)

même en mettant un ! devant ca exclue pas le réseau?

non, ça pete une erreur au moment ou tu démarre openswan.

après, c'est pas non plus prévu pour. le coup du 0.0.0.0/0 c'est un peu un hack
normalement, c'est fait pour de l'interconnexion de LAN, donc t'es censé connaitre et donner la liste de tes réseaux.