La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: jeremyp3 le 27 septembre 2020 à 10:26:09
-
bonjour,
j'ai un souci pas bloquant du tout mais estétiquement, je trouve ça moche. en effet, une machine online me sert de routeur bgp (je sais pas si c'est comme ça qu'on dit), et reçoit toute les route dans la table 222. le transitaire bgp, lui se fait avec un tunel gre. pour amener le préfix chez moi, j'utilise un wireguard, et un ip rule que je dirige aussi vers la table 222.
une règles du genre:
16383: from 2a0e:xxx:xxx:100a::/64 lookup 222
Dans le principe, tout ça fonctionne très bien, sauf un truc, lorsque je fais un mtr vers une de mes ips du préfix, au moment de passer sur la machine online qui a aussi de la v6 online, c'est l'ip online qui répond et pas l'ip du loopback que j'ai mis en défault sur la table 222
je ne sais pas quoi vraiment chercher sur le net pour essayer de résoudre ça
ce que j'ai testé en vrac:
rajouter dans les routes l'ip de loopback en src
différentes combinaisons ip route, ip rule, sans réussir a supprimer cette !$* ip de mes mtr ! :)
Je dois probablement faire quelque chose de mal, mais je vois pas quoi
Si il vous faut des sortie de commandes, n'hésitez pas
merci à vous si vous avez des idées
Jerem
-
bonjour,
je me permet de relancer ce sujet. personne n'a d'idée ?
merci,
Jerem
-
ip route xxx/xx src xxxx ?
-
re,
non. malheureusement j'avais testé ça dans ma conf de bird afin que toutes les routes reçu ait un src, mais le résultat est identique. par contre je l'ai pas testé sur les ip qui portent la session bgp mais je pense qu'on s'en moque ? :)
Jerem
-
Oui, pourtant ça je l'ai testé, ça marche bien... Chelou :/
-
j'éclaircis mon shéma réseau:
pour les tests, on va partir d'une seule machine sur internet
sur mon routeur bgp:
ip -6 route
local ::1 dev lo proto kernel metric 256
2001:678:984:xxx::16/127 dev tun0 proto kernel metric 256
2001:678:984:xxx::24/127 dev tun1 proto kernel metric 256
2001:bc8:xx:edxx::1 dev eth0 proto kernel metric 256
unreachable 2a0e:b107:xxxx::1 dev lo proto kernel metric 256 error -101
2a0e:b107:xxxx:1000::/56 dev vpn-test proto kernel metric 256
2a0e:b107:xxxx:1100::/56 dev client-home proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev tun0 proto kernel metric 256
fe80::/64 dev tun1 proto kernel metric 256
default via fe80::ce46:d6ff:feb2:c9f1 dev eth0 metric 1024
ip -6 route show table 222 |grep 2001:41d0:
2001:41d0:1:xxxx::/64 via 2001:678:984:xxx::16 dev tun0 src 2a0e:b107:xxxx::1 metric 1024
2001:41d0:fc00::/38 via 2001:678:984:xxx::16 dev tun0 proto bird metric 1024 2001:41d0::/32 via 2001:678:984:b00b:b00b:b00b:b00b:16 dev tun0 proto bird metric 1024
2001:41d0::/32 via 2001:678:984:xxx::16 dev tun0 proto bird metric 1024
si je fais un traceroute depuis 2001:41d0:1:xxxx:: vers 2a0e:b107:xxxx::1 ça fonctionne bien j'ai bien le serveur qui me répond avec l'ip 2a0e:b107:xxxx::1.
par contre, si je fais un tracert vers une ip du range 2a0e:b107:xxxx:1000::/56 ou 2a0e:b107:xxxx:1100::/56 j'ai toujours l'ip gw online qui me répond ...
je me demande si il me manque pas quelque chose entre la table 222 et la table main ...
voilà quelques explications complémentaires
Jerem
-
Du source routing avec la commande ip link ? Pour dire d'utiliser la bonne table quand la source est ton préfixe
Edit: ip rule bien sur 😉
-
tu voulais pas dire plutôt ip rule ? parce que ip link, je suis pas sûr
-
j'ai oublié de poster ma config ip rule, la voilà:
ip -6 rule
16383: from all lookup local
16383: from 2a0e:b107:xxxx:1100::/56 lookup 222
16383: from all fwmark 0x1 lookup 222
16383: from 2a0e:b107:xxxx:1000::/56 iif vpn-test lookup 222
32766: from all lookup main
-
tu configure comment 2a0e:b107:xxxx::1 sur le serveur ? (ou qu'affiche "ip -6 a").
ps: par défaut la 'source address selection' d'IPv6 s'applique ( https://tools.ietf.org/html/rfc6724#section-5 ) et dans ton cas on dirait que la règle 8 ne s'applique que si le serveur est la destination du traceroute.
-
bonjour,
comme ça:
ip -6 a show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
inet6 2a0e:b107:xxxx::1/128 scope global
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
pour l'ajouter je fais juste un ip -6 a add 2a0e:b107:xxxx::1/128 dev lo
Jerem
-
et
ip route get 2001:41d0:1:xxxx:: sur le serveur ca donne quoi ?
-
ça donne ça:
ip route get 2001:41d0:1:xxxx::
2001:41d0:1:xxxx:: from :: via fe80::ce46:d6ff:feb2:c9f1 dev eth0 src 2001:bc8:xxxx:ed00::1 metric 0
cache
mais ça pour le coup ça me semble normal parce que je peux contacter cette ip depuis mon ipv6 online.
Jerem
-
et
ip -6 route show table local donne quoi.
ps: j'ai pas fait gaffe mais ton "ip rule" a 4 lignes de meme priorité. ce n'est pas reco du tout.
-
ip -6 route show table local
local ::1 dev lo proto none metric 0
local 2001:678:984:xxxx::17 dev lo proto none metric 0
local 2001:678:984:xxxx::25 dev lo proto none metric 0
local 2001:bc8:xxxx:ed00::1 dev lo proto none metric 0
local 2a0e:b107:xxxx::1 dev lo proto none metric 0
anycast 2a0e:b107:xxxx:1000:: dev lo proto none metric 0
local 2a0e:b107:xxxx:1000::1 dev lo proto none metric 0
anycast 2a0e:b107:xxxx:1100:: dev lo proto none metric 0
local 2a0e:b107:xxxx:1100::1 dev lo proto none metric 0
anycast fe80:: dev lo proto none metric 0
anycast fe80:: dev lo proto none metric 0
anycast fe80:: dev lo proto none metric 0
local fe80::200:5efe:a3ac:2904 dev lo proto none metric 0
local fe80::200:5efe:a3ac:2904 dev lo proto none metric 0
local fe80::207:cbff:fe03:c47e dev lo proto none metric 0
ff00::/8 dev eth0 metric 256
ff00::/8 dev tun0 metric 256
ff00::/8 dev tun1 metric 256
ff00::/8 dev client-home metric 256
ff00::/8 dev vpn-test metric 256
-
ta regle "from 2a0e:b107:xxxx:1100::/56 lookup 222" qui enclenche la table 222 ne prend pas quand c'est le routeur lui-meme car le 'from' n'est pas matché.
c'est un peu la poule et l'oeuf...
on a:
2001:41d0:1:xxxx::/64 via 2001:678:984:xxx::16 dev tun0 src 2a0e:b107:xxxx::1 metric 1024
->la table 222 met src a 2a0e:b107:xxxx::1 quand on doit joindre "2001:41d0:1:xxxx::/64"
et pour activer cette table il faut:
que "from 2a0e:b107:xxxx:1100::/56 lookup 222" match.
mais le routeur n'utilise jamais 2a0e:b107:xxxx::1 comme adresse source sauf cas explicite (en réponse a un ping direct a cette adresse par exemple).
Il te faut donc modifier tes rules et tables en conséquence (en faisant gaffe ;))
-
re,
je fais plutôt mes tests sur une ip du range 2a0e:b107:xxxx:1000::/56. est-ce que le problème est le même pour ce cas si ?
parce que j'avoue que là comme ça je vois pas le souci :) peux tu être un peu plus explicite en parlant de 2a0e:b107:xxxx:1000::/56 plutôt ? :)
merci
Jerem
-
qu'importe l'adresse , le serveur ne prend jamais l'adresse que tu as ajouté au loopback de lui-meme donc le 'from' de la regle ne match pas donc la table 222 n'est pas utilisé.
il te faut une regle avec 'to A iif loopback lookup 222' comme match pour corriger le probleme.
iif NAME
select the incoming device to match. If the interface
is loopback, the rule only matches packets originating
from this host. This means that you may create separate
routing tables for forwarded and local packets and,
hence, completely segregate them.
avec A la ou les ranges que donc tu veux voir ton ipv6 particulier lors des traceroute venant de A.
-
bonjour,
effectivmeent, en faisant un truc comme ça ça fonctionne:
ip -6 rule add to 2001:41d0:1:xxxx::/64 iif lo table 222
sauf que du coup, 2001:41d0:1:xxxx:: ne peux plus contacter l'ip d'online en direct ...
ce n'est pas possible de faire le contraire ? en gros que si quelqu'un venant de n'importe où contact 2a0e:b107:390:1000::/56 ça soit la gw loopback qui réponde ? j'ai testé quelque trucs, mais je n'y suis pas arrivé :(
idéalement j'aimerai pouvoir utiliser ipv6 d'online pour les machines qui contact l'ipv6 d'online en direct, et la réponse du lloopback quand on contact une de mes ips de mon /56 sans que l'un est d'incidence sur l'autre ...
finalement j'aurais du faire un lxc ça aurait été moins compliqué :)
Jerem
-
oui en raffinant. Je regarderai cela demain ca m'intéresse aussi.
Apres dans l'absolu, pour les traceroute c'est a mon avis mieux d'afficher l'ip d'online car cela permet a un tiers de savoir que si y'a un souci de latence ou autre l'AS d'Online est concerné a un moment dans le trajet des paquets.
-
En IPv4 on fait traditionnellement cela avec du SNAT qui change l'adresse source en fonction de regles.
En IPv6 la SNAT n'est pas dispo partout et pas forcement recommandé. Il vaut mieux rester sur un "route ... src".
Le plus simple (relativement) serait d'utiliser un marquage avec ip6tables et un "ip rule" avec fwmark (que tu as déja je crois).
Pour limiter les disfonctionnements il ne faut marquer que les paquets icmpv6 du traceroute donc ceux de Type 3 ('time-exceeded'):
en syntax ip6tables:
-p icmpv6 --icmpv6-type time-exceeded
completer la règle ip6tables a construire avec:
- quelle destination ou pas quelle destination (-d ou ! -d) voir quelle interface (-i ...).
- la chaine est OUTPUT (vu que c'est paquets ayant le serveur pour origine).
- la table est "mangle" (pour alterer/marquer des paquets avant le routage)
- la target est MARK (-j MARK)
- la valeur du marquage doit correspondre a la valeur du fwmark qu'on a mis dans l'ip rule. (--set-mark 1)
la base est donc:
ip6tables -t mangle -A OUTPUT -p icmpv6 --icmpv6-type time-exceeded -j MARK --set-mark 1
et rajouter destination
comme cela les traceroutes devrait répondre avec l'ip que tu souhaite (grace au "src" dans la table 222).
en gros que si quelqu'un venant de n'importe où contact 2a0e:b107:390:1000::/56 ça soit la gw loopback qui réponde ?
ca donnerai un truc du genre (pas testé):
ip6tables -t mangle -A OUTPUT -p icmpv6 --icmpv6-type time-exceeded ! -d 2a0e:b107:390:1000::/56 -j MARK --set-mark 1
si pas a destination de 2a0e:b107:390:1000::/56
si icmpv6 de type time-exceeded (ttl a 0)
si OUTPUT (process local au serveur)
alors mettre la marque 1 sur le paquet.
il faut ensuite exploité ce marquage dans le 'ip rule' avec fwmark
Mais attention faut que ta table 222 soit cohérente avec ce que tu veux faire donc avoir le bon 'src' la ou il faut.
Du coup c'est mieux peut-être d'avoir une table a part rien que pour ce marquage vu que 222 sert déja a autre chose.
c'est vite compliqué pour peu de gain quand meme. Du coup autant faire du SNAT IPv6 ou rien :)
edit: typos
et en 2020 faut peut-être faire avec nftables plutot.
-
Mais attention faut que ta table 222 soit cohérente avec ce que tu veux faire donc avoir le bon 'src' la ou il faut.
peux tu développer cette partie ?
pour les test, j'ai dans ma table 222:
2001:41d0:1:xxxx::/64 via 2001:678:984:xxxx::16 dev tun0 src 2a0e
:b107:xxxx::1 metric 1024
maintenant quand je traceroute depuis 2001:41d0:1:xxxx:: à la place de l'ip online j'ai un "???" donc je suppose que aç fonctionne pas tout à fait :)
ah moins qu'il faut rajouter quelque chose dans la table 222 ou une autre table quelque chose en rapport avec l'interface lo, genre une ip route add default dev lo ?
Jerem
-
tu fais bien un "ip route flush cache" entre chaque test ?
peux tu développer cette partie ?
Juste que la table 222 sert déjà a autre chose du coup je ne suis pas certain qu'il soit bien de l'utiliser aussi pour cela.
le marquage ne sert que pour les paquets icmpv6 time-exceeded quand la destination n'est pas 2a0e:b107:390:1000::/56
Le marquage c'est la partie simple mais ensuite la partie 'route ... src' nettement moins car il faut le faire pour toute les routes ou tu veux que le changement ai lieu. Ca veut dire dupliquer des routes de la table par défaut et les mettre dans la nouvelle table.
Dans ton cas la route par défaut suffirait mais faut la dupliquer donc si elle dynamique c'est moins top:
résumé:
fait le ménage dans tes 'ip rule', une prio différente parr rule.
0: from all lookup local
10: from 2a0e:b107:xxxx:1100::/56 lookup 222
20: from 2a0e:b107:xxxx:1000::/56 iif vpn-test lookup 222
32766: from all lookup main
32767: from all lookup default
(si tu fais des 'ip rule add' ca devrait faire automatiquement mettre des nombres qui se suivent, en faisant les "ip rule add" dans le bon ordre)
table 223 (appelée "tracert" c'est plus simple que les nombres)
# creation table 223
echo -e "223\ttracert" >> /etc/iproute2/rt_tables
ip rule add fwmark 0x1 table tracert # ca doit être après 10 & 20
# dupliquer la gw de la table main en ajoutant src et table
ip -6 route add default via fe80::xxxxxxx src 2a0e:b107:xxxx::1 dev xxx table tracert
ca 'devrait' marcher... mais que pour les ip joinables par la route par défaut.
je te rejoins que c'est surement bien plus simple avec un container ou un lxd...
ou peut etre en utilisant des labels IPv6 ?
-
tu fais bien un "ip route flush cache" entre chaque test ?
non, je touchais juste a ip6tables dans un premier temps
ip -6 route add default via fe80::xxxxxxx src 2a0e:b107:xxxx::1 dev xxx table tracert
dans cette route là, pourquoi on ne met pas la gw d'online en src, puisqu'on fait appel a fe80 qui est sur eth0 et qui donc correspond à 2001:bc8:xxxx:xxxx::1 ?
dans mon cas, tout est statique.
Merci,
Jerem
-
dans cette route là, pourquoi on ne met pas la gw d'online en src, puisqu'on fait appel a fe80 qui est sur eth0 et qui donc correspond à 2001:bc8:xxxx:xxxx::1 ?
C'est la qu'on fait le changement d'adresse source justement. il faut mettre une ip du serveur.
C'est la meme chose que tu faisais deja dans la table 222.
t'es sur de bien comprendre 'src' dans les routes ?
-
C'est la qu'on fait le changement d'adresse source justement. il faut mettre une ip du serveur.
ok.
t'es sur de bien comprendre 'src' dans les routes ?
je ne sais pas trop l'expliquer mais:
genre ip route add 2001:41d0:1:xxxx::/64 via y:y:y:y src z:z:z:z:z
du coup, dans ce cadre là, quand le serveur reçois quelque chose depuis 2001:41d0:1:xxxx::/64 il dit que son adresse c'est z:z:z:z:z.
J'en conviens que je manque un peu de vocabulaire là-dessus. Mais bon, je cherche qu'à apprendre ! davantage dans la pratique que dans la théorie, mais je fais tout pour comprendre :)
désolé si tu penses perdre ton temps ce que je n'espère pas :)
Jerem
-
heu les routes c'est en sortie pas en entrée.
ip route add 2001:41d0:1:xxxx::/64 via y:y:y:y src z:z:z:z:z
= pour joindre "2001:41d0:1:xxxx::/64" il faut envoyer les paquets a y.y.y.y en prenant l'adresse source z:z:z:z
quand y'a pas "src", la machine prend l'adresse source de l'interface de sortie ou celle mis par l'application (en réponse a ping on répond avec l'adresse avec laquelle on a été pingé). ceci c'est pour le trafic qui sort de la machine mais issue d'un process local a la machine, pour le trafic qui traverse (cas d'un routeur) on ne touche pas a l'adresse source, on se contente de router en sortie (sauf dans le cas ou on fait du NAT par exemple).
exemple:
interface de sortie par défaut eth0 adresse e:e:e:e
ip route add A::/64 via y:y:y:y src z:z:z:z
ip route add B::/64 via y:y:y:y
ping A::1 -> la machine en A::1 voit des paquets ayant pour source z:z:z:z arrivés et répond en retour a z:z:z:z
ping B::1 -> la machine en B::1 voit des paquets ayant pour source e:e:e:e arrivés et répond en retour a e:e:e:e
mais la machine A::1 peut ping aussi e:e:e:e s'il elle a une route vers le réseau de e:e:e:e et B::1 peut ping z:z:z:z s'il elle a une route de son coté.
en routage et réseau, y'a rarement de la symétrie par défaut il faut donc toujours regarder ce qui se passe dans chaque sens.