Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1164 connectés 

  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  Debian - Xen server - Iptables - Nat - Webserver

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Debian - Xen server - Iptables - Nat - Webserver

n°1287301
hadrieno
Posté le 10-08-2011 à 21:26:18  profilanswer
 

Bonsoir à tous,
 
Je vous explique la situation :
 
Je suis en train de mettre en place un serveur 'qui fait tout', à base de virtualisation, afin surtout de ne pas avoir mon serveur web ; sur le même serveur que mes données..... et ca me fait en prime un bel exercice  :love:  
 
Donc une bonne debian, un moteur de virtualisation (Xen), un iptable pour du Nat, et derrière ce Nat 2 à 3 machine virtuelles potentiels ; on va rester sur 2 pour le moment, ne m'étant pas occupé de la dernière.
 
Mon réseau perso est composé de :
 
Internet ---- [Freebox (192.168.0.1) [ ----- ] Station de travail & Wifi (192.168.0.80-200)
                              |
                              L -------- [ Serveur Xen [ --------- ] Serveur web (192.168.1.123)
                                                     |
                                                     L ----------------- ] Serveur Data (192.168.2.123)
 
Je sais que j'aurais pu me passer d'iptables et du NAT, et laisser ce role à la Freebox, mais un peu SM sur les bords [:lucy-fair] , j'ai voulu (enfin !) m'attaquer à iptables / Netfilter.
 
Le serveur Xen ne doit etre accessible que par SSH, uniquement à partir d'adresses précises. OK
Les VMs, ne doivent être accessible par SSH, que par le Serveur Xen (je verrais ultérieurement si je passe outre, en remappant les ports SSH pour chaque machine + routage ; si une autre soluce merci d'exposer) OK.
Les machines ne doivent pas se voir entre elles. OK.
Les connections HTTP doivent être redirigé vers le serveur web. OK
Partage réseau redirigé vers le serveur de Data. OK
 
Et en prime, voici mes tables (merci de commenter, en bon, en mauvais, du moment que cela reste constructif) :
 

Code :
  1. Chain INPUT (policy DROP 10 packets, 937 bytes)
  2. pkts bytes target     prot opt in     out     source               destination
  3.     0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  4.     0     0 ACCEPT     tcp  --  eth0   *       192.168.0.80          0.0.0.0/0           tcp dpt:22
  5. 5760  442K ACCEPT     tcp  --  eth0   *       192.168.0.120         0.0.0.0/0           tcp dpt:22
  6.   664  117K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state ESTABLISHED
  7.     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
  8.     0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:161
  9.    27  1392 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
  10.     1    60 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW,RELATED,ESTABLISHED
  11.     0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/sec burst 5
  12.     0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x29/0x29
  13.     0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F
  14.     0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00
  15.     0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x06
  16.     0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x17/0x04
  17.     3   636 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW
  18.     0     0 DROP       all  -f  *      *       0.0.0.0/0            0.0.0.0/0
  19.     0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F
  20.     0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00
  21. Chain FORWARD (policy ACCEPT 94 packets, 18710 bytes)
  22. pkts bytes target     prot opt in     out     source               destination
  23.     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-out vif4.0 --physdev-is-bridged
  24.     0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-in vif4.0 --physdev-is-bridged udp spt:68 dpt:67
  25.     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-out vif4.0 --physdev-is-bridged
  26.     0     0 ACCEPT     all  --  *      *       192.168.2.123          0.0.0.0/0           PHYSDEV match --physdev-in vif4.0 --physdev-is-bridged
  27.     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-out vif3.0 --physdev-is-bridged
  28.     0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-in vif3.0 --physdev-is-bridged udp spt:68 dpt:67
  29.     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-out vif3.0 --physdev-is-bridged
  30.     0     0 ACCEPT     all  --  *      *       192.168.1.123          0.0.0.0/0           PHYSDEV match --physdev-in vif3.0 --physdev-is-bridged
  31.     0     0 DROP       tcp  --  *      *       192.168.0.1          0.0.0.0/0           tcp dpts:135:139
  32.     0     0 DROP       tcp  --  *      *       192.168.0.1          0.0.0.0/0           tcp dpt:445
  33. Chain OUTPUT (policy DROP 0 packets, 0 bytes)
  34. pkts bytes target     prot opt in     out     source               destination
  35. 5552  849K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
  36.     1    60 ACCEPT     tcp  --  *      *       192.168.2.250        192.168.2.123         tcp dpt:22
  37.     3   180 ACCEPT     tcp  --  *      *       192.168.1.250        192.168.1.123         tcp dpt:22
  38.     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
  39.     6   338 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
  40.     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport dports 80,443
  41.     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21
  42.     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:20
  43.     0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:161
  44.     2   168 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW,RELATED,ESTABLISHED
  45. Chain PREROUTING (policy ACCEPT 14 packets, 1545 bytes)
  46. pkts bytes target     prot opt in     out     source               destination
  47.     7   336 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:135:139 to:192.168.2.123
  48.     7   336 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:445 to:192.168.2.123
  49.     4   224 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 to:192.168.1.123
  50. Chain POSTROUTING (policy ACCEPT 4 packets, 224 bytes)
  51. pkts bytes target     prot opt in     out     source               destination
  52.    65  3996 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
  53.     0     0 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
  54.     0     0 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
  55. Chain OUTPUT (policy ACCEPT 2 packets, 104 bytes)
  56. pkts bytes target     prot opt in     out     source               destination


 
 
Jusqu'à présent, tout va bien dans le meilleur des mondes.... sauf que :
- avec la redirection du port 80, pas moyen de faire un apt-get avec les VMs.
- avec la redirection des ports SMB, cela limite le partage au serveur de Data.... comment je fais si je veux partager ma racine du serveur web pour mon dev ????  :D  
 
Pour la 1ère problématique, je bute ???? J'imagine qu'il y a une soluce purement réseau, mais je vois pas laquelle..... je ne vois que la soluce de changer mes règles iptables quand je fais mes updates de VMs....
 
Pour la 2ème, par contre, je n'en vois pas trop.... à part remapper les ports SMB au niveau routage (et du serveur web), mais cela impliquerait également de le faire également à la demande sur ma machine cliente.... pas très pratique....
 
Voila, merci d'avance de vos réponses !
 
 
Hadrieno


Message édité par hadrieno le 16-08-2011 à 17:10:01
mood
Publicité
Posté le 10-08-2011 à 21:26:18  profilanswer
 

n°1287375
roscocoltr​an
L'enfer c'est les utilisateurs
Posté le 11-08-2011 à 13:00:36  profilanswer
 

C'est pas plus simple de bridger les interface des deux machines virtuelles à l'interface XEN et de les gérer comme 2 machines indépendantes ?

 

edit: C'est ce que tu voulais dire par "Je sais que j'aurais pu me passer d'iptables et du NAT, et laisser ce role à la Freebox, mais un peu SM sur les bords  , j'ai voulu (enfin !) m'attaquer à iptables / Netfilter. " ?


Message édité par roscocoltran le 11-08-2011 à 13:01:49

---------------
"Your god is too small", Giordano Bruno, 1548 - 1600
n°1287477
fighting_f​alcon
Posté le 11-08-2011 à 22:24:36  profilanswer
 

1er problème : limite ta règle aux paquets dont le "state" est à "new"
 
2ème problème : la seule solution que je vois est de passer par un bridge plutôt que par du NAT. Eventuellement rajouter des règles iptables pour blinder ton serveur Xen et ses VMs.


---------------
[mon feed]
n°1287809
hadrieno
Posté le 16-08-2011 à 17:12:44  profilanswer
 

fighting_falcon a écrit :

1er problème : limite ta règle aux paquets dont le "state" est à "new" Pas con !
 
2ème problème : la seule solution que je vois est de passer par un bridge plutôt que par du NAT. Eventuellement rajouter des règles iptables pour blinder ton serveur Xen et ses VMs.


 
Pour le 2ème point, je vais y réfléchir.... Merci !
 
 
Je test ça dans le semaine


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  Debian - Xen server - Iptables - Nat - Webserver

 

Sujets relatifs
Mettre à jour Debian lenny vers Squeeze. Snapshot suffit ?debit scp, ftp, ubuntu server
Debian & pureFTP - Erreur de connexion[debian] gestion RAID5 avec mdadm
analyser les logs iptables via interface websyslog-ng et iptables
Equivalent de FileZilla Server sous CentOSstunnel sous Debian
Debian xserver-xorg-input-synaptics (Wheezy) et clic droitServeur debian : activer mail() php
Plus de sujets relatifs à : Debian - Xen server - Iptables - Nat - Webserver


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR