Nat on a stick

Le
Eric Masson
'Lut,

Cette fonctionnalité parfois utile, qui consiste à natter alors que la
machine ne dispose que d'une interface existe sur certains ios (voir
l'article suivant http://blogs.techrepublic.com.com/networking/?pH6).

Énoncé :

- 3 lans internes reliés en wan à base vpn et routés de bout en bout
- 1 des lans du dit wan est relié par vpn à un lan externe qui n'est pas
routé sur le reste du réseau.
- Les configurations présentes ne sont pas modifiables

Le but du jeu est de mettre en place sur le lan interne relié au lan
externe une machine faisant office de gateway vers ce dernier pour
les autres lans internes.

Cela ressemble typiquement à un cas d'application de la NAT, donc est-il
possible d'obtenir d'une linuxette ou d'un bsd un fonctionnement
de type nat on a stick ?

Existe-t-il une alternative que je n'aurais pas vu ?

Merci d'avance.

--
Je crois que le meilleur moyen, c'est une signature qui contient
toutes les signatures et de virer les mauvaises avant envoi.
-+- Ivan in : <http://www.le-gnu.net> : Je signe donc je suis -+-
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #20204591
Salut,

Eric Masson a écrit :

- 3 lans internes reliés en wan à base vpn et routés de bout en bout
- 1 des lans du dit wan est relié par vpn à un lan externe qui n'est pas
routé sur le reste du réseau.
- Les configurations présentes ne sont pas modifiables...

Le but du jeu est de mettre en place sur le lan interne relié au lan
externe une machine faisant office de gateway vers ce dernier pour
les autres lans internes.

Cela ressemble typiquement à un cas d'application de la NAT, donc est-il
possible d'obtenir d'une linuxette ou d'un bsd un fonctionnement
de type nat on a stick ?




On peut faire du "NAT on a stick" avec un noyau Linux et iptables
moyennant quelques précautions comme désactiver l'envoi d'ICMP redirect.
Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la
situation ci-dessus.
Eric Masson
Le #20205011
Pascal Hambourg
'Lut,

On peut faire du "NAT on a stick" avec un noyau Linux et iptables
moyennant quelques précautions comme désactiver l'envoi d'ICMP
redirect.



Ok, tu as un lien à recommander stp ?
J'ai trouvé quelque chose de similaire pour OpenBSD/pf entretemps.

Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la
situation ci-dessus.



Permettre à une machine sur un des lan internes qui n'a pas de
connectivité avec le lan externe d'en disposer au travers d'une machine
du lan qui dispose de la connectivité et qui va faire office de "proxy".

Je préfèrerais de loin revoir l'infra pour me passer de hacks de ce type
mais cela implique des imbroglios politiques pour obtenir un début de
commencement d'intérêt pour la problématique ainsi que du temps, dont je
ne dispose pas, pour obtenir des cellules infra une implémentation
correcte (Welcome to the real world, Neo...)

Si tu as d'autres idées, elles sont les bienvenues.

Merci.

--
Puisque les 3/4 des messages n'arrivent pas ou alors avec trois jours
de retard, votons la grève du ng pendant une semaine. Je sais que ça
va être dur pour certains qui sont accros, mais il y en a marre.
-+- f in GNU : Newsmaster, salaud ! Les neuneux auront ta peau ! -+-
Pascal Hambourg
Le #20206481
Eric Masson a écrit :
Pascal Hambourg
On peut faire du "NAT on a stick" avec un noyau Linux et iptables
moyennant quelques précautions comme désactiver l'envoi d'ICMP
redirect.



Ok, tu as un lien à recommander stp ?



Pas spécialement. La connaissance de base d'iptables et de ses cibles
NAT (SNAT, DNAT, MASQUERADE, NETMAP...) devrait suffire. Pour l'ICMP
redirect, voir dans /proc/sys/net/ipv4/conf/<interface>/send_redirects.

Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la
situation ci-dessus.



Permettre à une machine sur un des lan internes qui n'a pas de
connectivité avec le lan externe d'en disposer au travers d'une machine
du lan qui dispose de la connectivité et qui va faire office de "proxy".



Je ne vois toujours pas, désolé.
Qu'entends-tu par "pas de connectivité" ? Pas de route aller, pas de
route retour ?
Quel genre de NAT penses-tu faire ? NAT source, NAT destination, dans
quel sens ?
Eric Masson
Le #20210011
Pascal Hambourg
'Re,

Pas spécialement. La connaissance de base d'iptables et de ses cibles
NAT (SNAT, DNAT, MASQUERADE, NETMAP...) devrait suffire. Pour l'ICMP
redirect, voir dans /proc/sys/net/ipv4/conf/<interface>/send_redirects.



Ok.

Permettre à une machine sur un des lan internes qui n'a pas de
connectivité avec le lan externe d'en disposer au travers d'une machine
du lan qui dispose de la connectivité et qui va faire office de "proxy".



Je ne vois toujours pas, désolé.



Je dois m'être mal expliqué, rien de grave.
Un peut d'ascii-art :

+---------------+ +---------------+ +---------------+ +--------------+
| 192.168.4.100 +-+ 192.168.4.254 +-+ 192.168.1.254 +-+ 192.168.1.45 |
+---------------+ +---------------+ +-------+-------+ +--------------+
|
+----------------+ +-------+--------+
| 172.20.100.150 +-+ 127.20.100.254 |
+----------------+ +----------------+

192.168.4.254, 192.168.1.254 et 172.20.100.254 sont des routeurs dont je
ne peux pas altérer la configuration pour les raisons précédemment
exposées.

La machine 192.168.4.100 n'a pas de route pour 172.20.100/24
La machine 172.20.100.150 n'a pas de route pour 192.168.4/24
La machine 192.168.1.45 dispose d'une route pour 172.20.100/24
La machine 172.20.100.150 dispose d'une route pour 192.168.1/24

Quel genre de NAT penses-tu faire ? NAT source, NAT destination, dans
quel sens ?



Le but du jeu serait d'utiliser 192.168.1.45 comme machine de rebond
pour 192.168.4.100 et donc de procéder à une nat source sur
192.168.1.45 afin que les paquets à destination de 172.20.100.150
puissent arriver à destination.

Suis-je plus clair ?

Je pense que le problème qui va se poser sera de forcer le passage des
paquets issus de 192.168.4.100 par 192.168.1.45 (en l'absence de routeur
sur le chemin, avec un alias sur la carte réseau de 192.168.1.45, cela
passerait tout seul, mais là, je suis un peu sec...)

Je pense donc qu'il me faut un proxy et non pas une solution à base nat,
tu as déjà regardé du coté d'outils comme http://www.delegate.org/ ?

Encore merci.

--
Expliquez-moi, car je ne comprends pas ce qu'il se passe. Je n'ai jamais
écrit quoi que ce soit à propos d'un "fichier MIME multivolet" : d'où
vient donc cette citation apocryphe ?
-+-RA in : GNU - Neuneu abattu en plein multivol -+-
Pascal Hambourg
Le #20211031
Eric Masson a écrit :

Le but du jeu serait d'utiliser 192.168.1.45 comme machine de rebond
pour 192.168.4.100 et donc de procéder à une nat source sur
192.168.1.45 afin que les paquets à destination de 172.20.100.150
puissent arriver à destination.

Suis-je plus clair ?



Ouais, sauf ça ne marche pas. Tant que 192.168.1.45 n'a pas de route
pour 172.20.100.150 et les routeurs intermédiaires ne routent pas les
paquets envoyés par 192.168.1.45 à 172.20.100.150 jusqu'à 192.168.1.45,
le NAT source ne sert à rien car 192.168.1.45 ne recevra jamais les paquets.

Rappels :
Le NAT source sert quand la destination ne peut joindre la source,
c'est-à-dire quand la source n'est pas routée depuis la destination.
Le NAT destination sert quand la source ne peut joindre la destination,
c'est-à-dire quand la destination n'est pas routée depuis la source.

Là, si j'ai bien compris personne ne peut joindre personne et donc il
faudrait faire à la fois du NAT source et destination : par exemple
192.168.4.100 s'adresse à un port de 192.168.1.45 qui est redirigé vers
172.20.100.150. Cela s'apparente au fonctionnement d'un proxy ou d'un
relais de port.

Je pense que le problème qui va se poser sera de forcer le passage des
paquets issus de 192.168.4.100 par 192.168.1.45 (en l'absence de routeur
sur le chemin, avec un alias sur la carte réseau de 192.168.1.45, cela
passerait tout seul, mais là, je suis un peu sec...)



Voilà.

Je pense donc qu'il me faut un proxy et non pas une solution à base nat,
tu as déjà regardé du coté d'outils comme http://www.delegate.org/ ?



Je ne connais pas delegate, et après lecture rapide je n'arrive pas à
comprendre comment ça marche, si c'est un proxy transparent ou explicite
(genre SOCKS), comment on gère l'accès à plusieurs serveurs si c'est
transparent...
Pascal Hambourg
Le #20211021
Pascal Hambourg a écrit :

Ouais, sauf ça ne marche pas. Tant que 192.168.1.45 n'a pas de route



Correction : 192.168.4.100
Eric Masson
Le #20213221
Pascal Hambourg
'Re,

Voilà.



Merci de confirmer que la nat était une fausse bonne idée.

Je ne connais pas delegate, et après lecture rapide je n'arrive pas à
comprendre comment ça marche, si c'est un proxy transparent ou explicite
(genre SOCKS), comment on gère l'accès à plusieurs serveurs si c'est
transparent...



Il me semble qu'avec un setup de type relais tcp comme montré dans la
page suivante :
http://www.delegate.org/delegate/HowToDG.html#clproxy
Je devrais pouvoir arriver à mes fins.

Encore merci pour ton aide.

--
BJ> Faudrait pas me prendre pour un con. Merci
JB> Relis bien cette partie du thread, on n'officialise rien d'illégal.
-+- In :
Pascal Hambourg
Le #20213361
Eric Masson a écrit :

Merci de confirmer que la nat était une fausse bonne idée.



Heh ! je ne confirme rien du tout, je donne juste mon avis qui n'a que
la valeur que tu veux bien lui accorder.
Eric Masson
Le #20215271
Pascal Hambourg
'Lut,

Heh ! je ne confirme rien du tout, je donne juste mon avis qui n'a que
la valeur que tu veux bien lui accorder.



Ben, vu que je ne t'ai jamais vu pour le moment raconter de conneries
ici, ma confiance en ton avis est plutôt élevée ;)

--
Bien reçu message via groupes discussion, je te répond avec la touche "
répondre au groupe " en ayant sélectionné ton message. J'espère que tu le
recevra dans ta boîte de réception. Le café est en préparation.
-+- in Guide du Neuneu Usenet - Open up, open up -+-
Publicité
Poster une réponse
Anonyme