VPN NETMAP et port forwarding
crapoulou Messages postés 28195 Date d'inscription Statut Modérateur, Contributeur sécurité Dernière intervention -
Hello,
Afin d'avoir un bastion-vpn qui gère l'overlap des réseaux locaux adressés, (192.168.11.0/24), j'ai des tunnels IPSEC montés via un "updown sript" qui ajoute des règles de MARK et de NETMAP (mangle,
Exemple de règles de routage :
~# iptables -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination NETMAP all -- anywhere 100.64.1.0/24 mark match 0x2 to:192.168.11.0/24 Chain POSTROUTING (policy ACCEPT) target prot opt source destination NETMAP all -- 10.1.0.0/24 anywhere mark match 0x2 to:100.64.0.0/16 ~# iptables -L -t mangle Chain PREROUTING (policy ACCEPT) target prot opt source destination MARK all -- anywhere 100.64.1.0/24 MARK set 0x2
Ainsi, j'assigne le réseau 100.64.1.0/24 au réel réseau terrain 192.168.11.0/24 en post routing et le marquage permet d'envoyer le paquet dans le bon tunnel VPN. Juste là tout va bien.
Pour que les règles de pre-routing fonctionne, j'ai un serveur en frontal (bastion-ssh) qui route les paquets à destination de ce réseau virtuel 100.64.0.0/10 vers mon bastion-vpn
Si je veux ssh la machine 192.168.11.100, je ferai :
ssh user@100.64.1.100 -J bastion-ssh
Mon problème :
Je veux port-forward le port 443 du routeur distant (adresse locale 192.168.11.254)
Logiquement, je devrais faire :
ssh -N -f -L 1443:100.64.1.254:443 bastion-ssh
Or, cela ne fonctionne pas !
- tcpdump, aucun paquet n'arrive à "bastion-vpn" !
- tcpdump : sur bastion ssh, le paquet arrive en "Out IP" :
09:22:59.787563 eth0 Out IP 10.1.0.1.41400 > 100.64.11.254.https
J'ai l'impression que ce bastion SSH n'utilise pas sa table de routage pour envoyer le paquet et le transmettre à bastion-vpn : le paquet est perdu.
J'ai tenté un double proxyjump, mais rien ne va. Si je fait un port forward directement via bastion-vpn, les règles de prerouting et de marquage de paquet ne se font pas (cf. schéma de routage)
Si quelqu'un a une idée sur ce problème assez complexe, je suis preneur ! Une astuce pour que le routage en port forwarding se fasse finalement de la même manière que sur un SSH via proxyjump...
Merci d'avance !
- VPN NETMAP et port forwarding
- Vpn comment ça marche - Guide
- Vpn gratuit - Accueil - Guide VPN
- Advanced port scanner - Télécharger - Utilitaires
- Hola vpn chrome - Guide
- Vpn iptv forum ✓ - Forum Box et Streaming vidéo
2 réponses
Salut,
NETMAP all -- 10.1.0.0/24 anywhere mark match 0x2 to:100.64.0.0/16
il ne faut pas des tailles égales ? /24 vers /24 ?
Par contre ta cuisine SSH, je n'ai pas compris, tu devrais peut-etre déplacer dans linux
ah, c'est ça le bastion .... ?
C'est récent comme système, je comprends que je n'en avais pas encore entendu parler.
par contre dans ce cas, je ne vois pas le rapport avec le netmap, c'est justement pour empêcher l'entrée via netmap le truc.
C'est que le réseau 192.168.11.0/24 existe des deux bouts du vpn ?
Hello !
Alors pour les réseaux à taille égale, ça fonctionne en tout cas, mais ça doit pas être clean, t'as raison.
En effet, le bastion me sert de rebond pour arriver sur des serveurs sur des sites distants ensuite le bastion.
Le réseau 192.168.11.0/24 existe sur tous mes sites distants. Du coup, je ne peux pas adresser depuis un PC client les différents serveurs sans réseau virtuellement assigné à chaque site :-/
Le même réseau partout, ce sera toujours un problème, les proxy et les nat c'est du bricolage, à chaque nouveau protocole à router, chaque adresse ajoutée, il faut reprendre toute la cuisine.
Une bonne renumérotation une fois pour toutes et tu serais tranquille au niveau routage et parefeu.
C'est lourd une seule fois, pas tout le temps.
Après, pour l'administration des serveurs ou des tunnels, tu peux rajouter de l'ipv6 en double stack et garder juste les applis métier en ipv4 dans ce routage merdique.
En fait il faut que je scope mieux mes réseau par site (pas du /24 par exemple), mais faut que je vois comment ça fonctionne.
Je ne peux pas modifier le réseau distant qui est industriel, contraint et identique partout.
On avait des tunnels IPv6 mais portés par des PC et non des équipements réseaux. L'objectif est de faire porter ça par un routeur plutôt et que côté client, les NETMAP soient transparents.
Par contre, la double stack ipv4/ipv6, il faut que j'étudie si ça peut résoudre mon problème ou complexifier l'archi.
Pour reprendre le problème initial (port forward + mark&netmap), j'ai abandonné, je pense que ce n'est pas possible :-(