Ce billet est un petit exercice de style 🙂
Dans le cadre d’une architecture « standard », vous disposez d’un routeur qui vous donne accès au Nain Ternet, un firewall dédié et vos serveurs.
Les serveurs dédiés à offrir des services aux utilisateurs externes sont normallement en DMZ.
Ca c’est le cas idéal, mais il peut arriver (souvent même), que quelques applications soient hébergées sur des serveurs du LAN et là on joue avec de la NAT dans tout les sens.
Vous avez donc ouvert le port sur votre firewall puis fait une redirection sur la machine dans le LAN.
Ca marche mais bof quoi 😉
Dans ce genre de concept (très fréquent), on laisse donc la transaction TCP (le fameux 3-way handshake) s’établir entre le client et le serveur dans le LAN.
Moyen hein ?
Après tout, vous obligez bien vos utilisateurs à passer par un proxy Squid pour aller sur le Web, pourquoi ne pas faire pareil avec vos connexions entrantes TCP ?…
Voila ce que nous allons mettre en place :
Schéma
Et qui a la plus de compétences pour gérer le 3-way handshake a la place des autres ? Qui a la plus grosse quand on parle de couche réseau ?
Réponse : OpenBSD forcement
Nous allons partir du principe que vous désirez offrir un accès SMTP sur la machine LAN-MAIL depuis le Nain Ternet.
L’adressage utilisée sera le suivant (et comme toujours un dessin valant mieux qu’un grand discours) :
Schéma
Coté Firewall, redirection toute simple, tout ce qui entre sur le port 25 SMTP depuis le Net sur l’interface externe est redirigé sur 10.154.1.1 port 25 (ou autre hein, c’est vous qui voyez).
La, c’est du truc habituel, rien de bien sorcier.
Coté OpenBSD, on va se monter un petit socket :
vi /etc/inetd.conf 127.0.0.1:5025 stream tcp nowait nobody /usr/bin/nc nc 192.168.0.50 25 |
On reload le process inetd
Puffy:~# ps aux | grep inetd root 24243 0.0 0.3 524 780 ?? Is 26Sep08 0:18.06 inetd root 30919 0.0 0.3 472 764 p0 S+ 11:23AM 0:00.02 grep inetd Puffy:~# kill -HUP 24243 |
Explication, on utilise netcat pour établir une connexion tcp vers LAN-MAIL sur le port 25 quand une requète TCP arrive sur son port 5025 en localhost.
Maintenant on s’attaque à la couche la plus poilue, Packet Filter :
(wan_if étant l’interface sis0 dans le schéma)
pf.conf rdr pass on $wan_if inet proto tcp from any to $wan_if port 25 --> 127.0.0.1 port 5025 pass in quick inet proto tcp from any to 127.0.0.1 port 5025 |
Et c’est tout.
Bien évidemment vous avez déjà un beau PF configuré avec toutes les options qui vont bien, antispoof, scrub in all et tout, et tout…
J’ai volontairement simplifié l’architecture et les règles, alors ne me criez pas dessus 😀
Et ca fait quoi donc maintenant ce joli truc ?
Cela fait que désormais, c’est l’OpenBSD qui va traiter la connexion entrante, l’accepter, ouvrir une nouvelle connexion vers LAN-MAIL et véhiculer les paquets vers lui.
Toute la phase d’échange TCP sera traitée par le BSD et c’est avec lui que le client discutera directement.
Bref, l’OpenBSD joue le rôle de Proxy TCP 🙂
Voila pour ce petit exercice que je vous laisse peaufiner et qui peut vous dépatouiller d’architectures un peu compliqués ou surtout, de connexions TCP moisies entre le Firewall et le Serveur final.
P.S. : Attention avec le protocole FTP, ce n’est aussi simple que cela y parait. Je vous conseille fortement d’utiliser le programme ftp-proxy d’openBSD (surtout si vous voulez redirigez vos requêtes FTP externes vers le FTP de votre Freebox HD par exemple 😉 )
