Problème de réseau domestique

Problème de réseau domestique - Linux et OS Alternatifs

Marsh Posté le 10-04-2004 à 00:39:25    

Bonjour à tous,
Voilà mon problème, ça fait trop de nuits blanches que je suis dessus pour ne pas demander de l'aide.
 
J'ai deux portables, un sous mandrake 9.2 l'autre sur Windaube XP Home chacun n'ayant qu'une seule carte réseau.
J'ai un modeme Sagem USB 908, free dégroupé.
 
Voici mon objectif:
Utiliser la mandrake comme passerelle internet pour XP home,
Utiliser le partage de fichiers entre les 2 ordis,
Me servir de la mandrake comme serveur Apache, (et serveur Samba3 pour le partage des fichiers)
 
J'ai suivi les conseils de plusieurs topics, notamment http://www.lea-linux.org/reseau/samba.php3.
 
Mais ça ne marche jamais lorsque j'essaye d'atteindre le swat : "impossible de se connecter à localhost:901".  
j'arrive parfois à atteindre Windaube avec le partage de KDE mais très vite tout replante et j'obtiens "smdb est mort".
 
De plus, j'arrive à utiliser la connection USB grâce à eagleusb.196 mais dès que je tente de partager la connexion internet, celle-ci n'est plus détectée alors que le modem semble opérationnel (2 voyants allumés).
Evidemment, il y a bien la solution (qui marche) de brancher le modem USb sur windaube, mais le niveau de sécurité doit y perdre beaucoup, ce qui me pose problème pour mon serveur Apache et pour l'ordi windaube.
 
Que me conseillez vous? (à part utiliser windaube sur les deux ordis)


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 10-04-2004 à 00:39:25   

Reply

Marsh Posté le 12-04-2004 à 15:32:34    

Il n'y a rien à faire c'est ça????


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 12-04-2004 à 15:58:54    

Pour faire fonctionnet SWAT il faut décommenter la ligne le concernant dans /etc/inetd.conf puis relancer le service inetd.
 
Quand à ton modem je ne le connais pas, donc je peux pas t'aider.

Reply

Marsh Posté le 12-04-2004 à 17:38:43    

Ce qu'il faut savoir , c'est que quand tu lance le partage de connexion dans le mandrake control center, il lance aussi un firewall (Shorewall) qui laisse rien passer par défaut . Donc il sera surement necessaire de lui indiquer quoi laisser passer .
Pour configurer shorewall :  
www.shorewall.net
/etc/shorewall/rules
/etc/shorewall/interfaces
/etc/shorewall/zones
 
Puis (en root): shorewall restart

Reply

Marsh Posté le 12-04-2004 à 18:08:26    

ok merci beaucoup je vais déjà essayer ça


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 12-04-2004 à 18:08:59    

desactiver shorewall aussi, enfin dans un premier temps ;)

Reply

Marsh Posté le 12-04-2004 à 18:34:28    

ccp6128> pour mdk c'est xinetd qui gère et non plus inetd et c'est dans /etc/xinetd.d/swat où il faut mettre "disable=no"
 
swat est dans un rpm à part
autres possibilitées -> http://www.linux-wizard.net/faq_basique2.html#lan
 
pour le partage de connexioçn et la perte, je pense que c'est parce que il ne sélectionne pas la bonne interface pour le partage. Avec la 10.0 on peut sélectionner, tu peux sélectionner l'interface avec la 9.2  ? l'interface à sélectionner est ppp0


---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Reply

Marsh Posté le 12-04-2004 à 22:58:44    

Pour xinetd j'avais déjà bien configuré mais je vais tout refaire.
 
Par contre pour le partage de connexion je suis sûr que c'est ce que tu dis, mais je n'ai pas vraiment de choix.
En fait, une fois que j'ai réussi à installer internet via USB quelle est la bonne procédure à suivre pour partager la connexion avec une seule carte réseau (j'ai essayé plusieurs trucs mais ça m'annule ma connexion internet, et ça me la remplace par la connexion réseau) ? Pourais tu me décrire pas à pas la procédure?  
Merci beaucoup d'avance


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 12-04-2004 à 23:27:08    

je n'ai pas très bien compris le problème, mais vu ton modem si tu as des questions sur la connexion internet tu trouveras sans doute des réponses sur le site du driver : http://eagle-usb.ath.cx/pub/sommaire.php3
Désolé si ça n'est pas en rapport avec la question :/

Reply

Marsh Posté le 13-04-2004 à 00:27:52    

Le lien ne répond pas directement à mon pb mais merci pour le geste.
En fait, je veux bien désinstaller complétement ma Mandrake 9.2 pour remettre dirctement la bonne config, si vous pouviez m'indiquer la bonne procédure de partage de connexion internet USB vers mon réseau local.


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 13-04-2004 à 00:27:52   

Reply

Marsh Posté le 13-04-2004 à 01:45:30    

merci pour la précision Dark, j'avais pas percuté que c'était une Mandrake.

Reply

Marsh Posté le 14-04-2004 à 13:38:04    

une fois que j'ai réinstallé mandrake, que j'ai installé la connexion USB que faut-il faire?


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 14-04-2004 à 14:05:21    

Normalementr pour partager une connexion internet, il suffit de lancer l'assistant de la mdk ( drakgw ), mais le problème est qu'il doit sélectionner la bonne interface. tu testes et tu dis ce que tu as fais et les choix qui t'était proposés


---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Reply

Marsh Posté le 14-04-2004 à 14:09:16    

par défaut on me propose ppe+ lorsque je lance l'assistant, je continue, ensuite on me demande si je veux l'interface etho 81... ou eth1. Que je séléctionne l'une ou l'autre, la connexion avec l'autre ordinateur fonctionne mais elle annule ma connexion internet usb.


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 14-04-2004 à 14:11:43    

le modem est lié à kelle interface ?
 
le sagem usb crée une interface réseau virtuelle ...
 
donc cherche lequel est lié à une vrai carte réseau :
> grep eth /etc/modules.conf


---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Reply

Marsh Posté le 14-04-2004 à 14:13:18    

par défault il se met en eth0


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 14-04-2004 à 14:15:23    

alors c'est eth1 la carte qu'il faut sélectionner comme carte à laquelle est reliée le réseau local
peux tu montrer le contenu des fichiers dans /etc/shorewall ?


---------------
Mandriva : parce que nous le valons bien ! http://linux-wizard.net/index.php
Reply

Marsh Posté le 14-04-2004 à 14:20:02    

merci, je réésaye tout ça et je te publierai ce fichier car pour l'instant je suis obligé de me connecter sous windaube


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 14-04-2004 à 20:16:26    

Voilà ce que j'ai fait:
Réinstallation complète de mandrake 9.2. Installation de ma connexion internet Sagem 908 Free Dégroupé par USB via eagle1.6. La connexion internet marche. Puis partage de connexion avec l'assistant : j'ai tapé ppp0 puis sélectionné interface eth1. tout s'installe bien. Pare feu : tout laisser passer (pas de pare feu). Puis de nouveau connexion internet désactivée, remplacée par la connexion réseau.
 
 
Voilà mon fichier shorewall
 
##############################################################################
#  /etc/shorewall/shorewall.conf V1.4 - Change the following variables to
#  match your setup
#
#  This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]
#
#  This file should be placed in /etc/shorewall
#
#  (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net)
##############################################################################
#                              L O G G I N G
##############################################################################
#
# General note about log levels. Log levels are a method of describing
# to syslog (8) the importance of a message and a number of parameters
# in this file have log levels as their value.
#
# Valid levels are:
#
# 7 debug
# 6 info
# 5 notice
# 4 warning
# 3 err
# 2 crit
# 1 alert
# 0 emerg
#
# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall
# log messages are generated by NetFilter and are logged using facility
# 'kern' and the level that you specifify. If you are unsure of the level
# to choose, 6 (info) is a safe bet. You may specify levels by name or by
# number.
#
# If you have build your kernel with ULOG target support, you may also
# specify a log level of ULOG (must be all caps). Rather than log its
# messages to syslogd, Shorewall will direct netfilter to log the messages
# via the ULOG target which will send them to a process called 'ulogd'.
# ulogd is available from http://www.gnumonks.org/projects/ulogd and can be
# configured to log all Shorewall message to their own log file
################################################################################
#
# LOG FILE LOCATION
#
# This variable tells the /sbin/shorewall program where to look for Shorewall
# log messages. If not set or set to an empty string (e.g., LOGFILE="" ) then
# /var/log/messages is assumed.
#
# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to
#          look for Shorewall messages.It does NOT control the destination for
#          these messages. For information about how to do that, see
#
#              http://www.shorewall.net/shorewall_logging.html
 
LOGFILE=/var/log/messages
 
#
# LOG FORMAT
#
# Shell 'printf' Formatting template for the --log-prefix value in log messages
# generated by Shorewall to identify Shorewall log messages. The supplied
# template is expected to accept either two or three arguments; the first is
# the chain name, the second (optional) is the logging rule number within that
# chain and the third is the ACTION specifying the disposition of the packet
# being logged. You must use the %d formatting type for the rule number; if your
# template does not contain %d then the rule number will not be included.
#
# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:
#
# LOGFORMAT="fp=%s:%d a=%s "
#
# If not specified or specified as empty (LOGFORMAT="" ) then the value
# "Shorewall:%s:%s:" is assumed.
#  
# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up  
# to but not including the first '%') to find log messages in the 'show log',
# 'status' and 'hits' commands. This part should not be omitted (the  
# LOGFORMAT should not begin with "%" ) and the leading part should be
# sufficiently unique for /sbin/shorewall to identify Shorewall messages.
 
LOGFORMAT="Shorewall:%s:%s:"
 
#
# LOG RATE LIMITING
#
# The next two variables can be used to control the amount of log output
# generated. LOGRATE is expressed as a number followed by an optional
# `/second',  `/minute', `/hour', or `/day' suffix and specifies the maximum
# rate at which a particular message will occur. LOGBURST determines the
# maximum initial burst size that will be logged. If set empty, the default
# value of 5 will be used.
#
# Example:
#
# LOGRATE=10/minute
# LOGBURST=5
#
# If BOTH variables are set empty then logging will not be rate-limited.
#
 
LOGRATE=
LOGBURST=
 
#
# LEVEL AT WHICH TO LOG 'UNCLEAN' PACKETS
#
# This variable determines the level at which Mangled/Invalid packets are logged
# under the 'dropunclean' interface option. If you set this variable to an
# empty value (e.g., LOGUNCLEAN= ), Mangled/Invalid packets will be dropped
# silently.
#
# The value of this variable also determines the level at which Mangled/Invalid
# packets are logged under the 'logunclean' interface option. If the variable
# is empty, these packets will still be logged at the 'info' level.
#
# See the comment at the top of this section for a description of log levels
#
 
LOGUNCLEAN=info
 
#
# BLACKLIST LOG LEVEL
#
# Set this variable to the syslogd level that you want blacklist packets logged
# (beware of DOS attacks resulting from such logging). If not set, no logging
# of blacklist packets occurs.
#
# See the comment at the top of this section for a description of log levels
#
BLACKLIST_LOGLEVEL=
 
#
# LOGGING 'New not SYN' rejects
#
# This variable only has an effect when NEWNOTSYN=No (see below).
#
# When a TCP packet that does not have the SYN flag set and the ACK and RST
# flags clear then unless the packet is part of an established connection,
# it will be rejected by the firewall. If you want these rejects logged,
# then set LOGNEWNOTSYN to the syslog log level at which you want them logged.
#
# See the comment at the top of this section for a description of log levels
#
# Example: LOGNEWNOTSYN=debug
 
 
LOGNEWNOTSYN=info
 
#
# MAC List Log Level
#
# Specifies the logging level for connection requests that fail MAC
# verification. If set to the empty value (MACLIST_LOG_LEVEL="" ) then
# such connection requests will not be logged.
#
# See the comment at the top of this section for a description of log levels
#
 
MACLIST_LOG_LEVEL=info
 
#
# TCP FLAGS Log Level
#
# Specifies the logging level for packets that fail TCP Flags
# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="" ) then
# such packets will not be logged.
#
# See the comment at the top of this section for a description of log levels
#
 
TCP_FLAGS_LOG_LEVEL=info
 
#
# RFC1918 Log Level
#
# Specifies the logging level for packets that fail RFC 1918
# verification. If set to the empty value (RFC1918_LOG_LEVEL="" ) then
# RFC1918_LOG_LEVEL=info is assumed.
#
# See the comment at the top of this section for a description of log levels
#
 
RFC1918_LOG_LEVEL=info
 
################################################################################
#       L O C A T I O N   O F   F I L E S   A N D   D I R E C T O R I E S
################################################################################
#
# PATH - Change this if you want to change the order in which Shorewall
#        searches directories for executable files.
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
 
#
# SHELL
#
# The firewall script is normally interpreted by /bin/sh. If you wish to change
# the shell used to interpret that script, specify the shell here.
 
SHOREWALL_SHELL=/bin/sh
 
# SUBSYSTEM LOCK FILE
#
# Set this to the name of the lock file expected by your init scripts. For
# RedHat, this should be /var/lock/subsys/shorewall. On Debian, it
# should be /var/state/shorewall. If your init scripts don't use lock files,
# set this to "".
#
 
SUBSYSLOCK=/var/lock/subsys/shorewall
 
#
# SHOREWALL TEMPORARY STATE DIRECTORY
#
# This is the directory where the firewall maintains state information while
# it is running
#
 
STATEDIR=/var/lib/shorewall
 
#
# KERNEL MODULE DIRECTORY
#
# If your netfilter kernel modules are in a directory other than
# /lib/modules/`uname -r`/kernel/net/ipv4/netfilter then specify that
# directory in this variable. Example: MODULESDIR=/etc/modules.
 
MODULESDIR=
 
################################################################################
#                       F I R E W A L L   O P T I O N S
################################################################################
 
# NAME OF THE FIREWALL ZONE
#
# Name of the firewall zone -- if not set or if set to an empty string, "fw"
# is assumed.
#
FW=fw
 
#
# ENABLE IP FORWARDING
#
# If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you
# say "Off" or "off", packet forwarding will be disabled. You would only want
# to disable packet forwarding if you are installing Shorewall on a
# standalone system or if you want all traffic through the Shorewall system
# to be handled by proxies.
#
# If you set this variable to "Keep" or "keep", Shorewall will neither
# enable nor disable packet forwarding.
#
IP_FORWARDING=On
 
#
# AUTOMATICALLY ADD NAT IP ADDRESSES
#
# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
# for each NAT external address that you give in /etc/shorewall/nat. If you say
# "No" or "no", you must add these aliases youself.
#
ADD_IP_ALIASES=Yes
 
#
# AUTOMATICALLY ADD SNAT IP ADDRESSES
#
# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses
# for each SNAT external address that you give in /etc/shorewall/masq. If you say
# "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No" unless
# you are sure that you need it -- most people don't!!!
#
ADD_SNAT_ALIASES=No
 
#
# ENABLE TRAFFIC SHAPING
#
# If you say "Yes" or "yes" here, Traffic Shaping is enabled in the firewall. If
# you say "No" or "no" then traffic shaping is not enabled. If you enable traffic
# shaping you must have iproute[2] installed (the "ip" and "tc" utilities) and
# you must enable packet mangling above.
#
TC_ENABLED=No
 
#
# Clear Traffic Shapping/Control
#
# If this option is set to 'No' then Shorewall won't clear the current
# traffic control rules during [re]start. This setting is intended
# for use by people that prefer to configure traffic shaping when
# the network interfaces come up rather than when the firewall
# is started. If that is what you want to do, set TC_ENABLED=Yes and
# CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That
# way, your traffic shaping rules can still use the 'fwmark'
# classifier based on packet marking defined in /etc/shorewall/tcrules.
#
# If omitted, CLEAR_TC=Yes is assumed.
 
CLEAR_TC=Yes
 
#
# Mark Packets in the forward chain
#
# When processing the tcrules file, Shorewall normally marks packets in the
# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set
# this to "Yes". If not specified or if set to the empty value (e.g.,
# MARK_IN_FORWARD_CHAIN="" ) then MARK_IN_FORWARD_CHAIN=No is assumed.
#
# Marking packets in the FORWARD chain has the advantage that inbound
# packets destined for Masqueraded/SNATed local hosts have had their destination
# address rewritten so they can be marked based on their destination. When
# packets are marked in the PREROUTING chain, packets destined for
# Masqueraded/SNATed local hosts still have a destination address corresponding
# to the firewall's external interface.
#
# Note: Older kernels do not support marking packets in the FORWARD chain and
#       setting this variable to Yes may cause startup problems.
 
MARK_IN_FORWARD_CHAIN=No
 
#
# MSS CLAMPING
#
# Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU"
# option. This option is most commonly required when your internet
# interface is some variant of PPP (PPTP or PPPoE). Your kernel must
# have CONFIG_IP_NF_TARGET_TCPMSS set.
#
# [From the kernel help:
#
#    This option adds a `TCPMSS' target, which allows you to alter the
#    MSS value of TCP SYN packets, to control the maximum size for that
#    connection (usually limiting it to your outgoing interface's MTU
#    minus 40).
#
#    This is used to overcome criminally braindead ISPs or servers which
#    block ICMP Fragmentation Needed packets.  The symptoms of this
#    problem are that everything works fine from your Linux
#    firewall/router, but machines behind it can never exchange large
#    packets:
#        1) Web browsers connect, then hang with no data received.
#  2) Small mail works fine, but large emails hang.
#  3) ssh works fine, but scp hangs after initial handshaking.
# ]
#
# If left blank, or set to "No" or "no", the option is not enabled.
#
CLAMPMSS=No
 
#
# ROUTE FILTERING
#
# Set this variable to "Yes" or "yes" if you want kernel route filtering on all
# interfaces (anti-spoofing measure).
#
# If this variable is not set or is set to the empty value, "No" is assumed.
# In that case, you can still enable route filtering on individual interfaces
# in the /etc/shorewall/interfaces file.
 
ROUTE_FILTER=No
 
#
# NAT BEFORE RULES
#
# Shorewall has traditionally processed static NAT rules before port forwarding
# rules. If you would like to reverse the order, set this variable to "No".
#
# If this variable is not set or is set to the empty value, "Yes" is assumed.
 
NAT_BEFORE_RULES=Yes
 
# DNAT IP ADDRESS DETECTION
#
# Normally when Shorewall encounters the following rule:
#
# DNAT net loc:192.168.1.3 tcp 80
#
# it will forward TCP port 80 connections from the net to 192.168.1.3
# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is
# convenient for two reasons:
#
# a) If the the network interface has a dynamic IP address, the
#    firewall configuration will work even when the address
#    changes.
#
# b) It saves having to configure the IP address in the rule
#    while still allowing the firewall to be started before the
#    internet interface is brought up.
#
# This default behavior can also have a negative effect. If the
# internet interface has more than one IP address then the above
# rule will forward connection requests on all of these addresses;
# that may not be what is desired.
#
# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply
# only if the original destination address is the primary IP address of
# one of the interfaces associated with the source zone. Note that this
# requires all interfaces to the source zone to be up when the firewall
# is [re]started.
 
DETECT_DNAT_IPADDRS=No
 
#
# MUTEX TIMEOUT
#
# The value of this variable determines the number of seconds that programs
# will wait for exclusive access to the Shorewall lock file. After the number
# of seconds corresponding to the value of this variable, programs will assume
# that the last program to hold the lock died without releasing the lock.
#
# If not set or set to the empty value, a value of 60 (60 seconds) is assumed.
#
# An appropriate value for this parameter would be twice the length of time
# that it takes your firewall system to process a "shorewall restart" command.
 
MUTEX_TIMEOUT=60
 
#
# NEWNOTSYN
#
# If this variable is set to "No" or "no", then when a TCP packet that does
# not have the SYN flag set and the ACK and RST flags clear then unless the
# packet is part of an established connection, it will be dropped by the
# firewall
#
# If this variable is set to "Yes" or "yes" then such packets will not be
# dropped but will pass through the normal rule processing.
#
# Users with a High-availability setup with two firewall's and one acting
# as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may
# also need to select NEWNOTSYN=Yes.
#
# The behavior of NEWNOTSYN=Yes may also be enabled on a per-interface basis  
# using the 'newnotsyn' option in /etc/shorewall/interfaces.
 
NEWNOTSYN=No
 
################################################################################
#                       P A C K E T   D I S P O S I T I O N
################################################################################
#
# BLACKLIST DISPOSITION
#
# Set this variable to the action that you want to perform on packets from
# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,
# DROP is assumed.
#
BLACKLIST_DISPOSITION=DROP
 
#
# MAC List Disposition
#
# This variable determines the disposition of connection requests arriving
# on interfaces that have the 'maclist' option and that are from a device
# that is not listed for that interface in /etc/shorewall/maclist. Valid
# values are ACCEPT, DROP and REJECT. If not specified or specified as
# empty (MACLIST_DISPOSITION="" ) then REJECT is assumed
 
MACLIST_DISPOSITION=REJECT
 
#
# TCP FLAGS Disposition
#
# This variable determins the disposition of packets having an invalid
# combination of TCP flags that are received on interfaces having the
# 'tcpflags' option specified in /etc/shorewall/interfaces. If not specified
# or specified as empty (TCP_FLAGS_DISPOSITION="" ) then DROP is assumed.
 
TCP_FLAGS_DISPOSITION=DROP
 
#LAST LINE -- DO NOT REMOVE


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 14-04-2004 à 20:45:25    

Tu devrais montrer aussi /etc/shorewall/rules, et /etc/shorewall/policy

Reply

Marsh Posté le 14-04-2004 à 22:10:33    

etc/shorewall/rules:
 
#
# Shorewall version 1.4 - Rules File
#
# /etc/shorewall/rules
#
# Rules in this file govern connection establishment. Requests and
# responses are automatically allowed using connection tracking.
#
# In most places where an IP address or subnet is allowed, you
# can preceed the address/subnet with "!" (e.g., !192.168.1.0/24) to
# indicate that the rule matches all addresses except the address/subnet
# given. Notice that no white space is permitted between "!" and the
# address/subnet.
#
# Columns are:
#
#
# ACTION  ACCEPT, DROP, REJECT, DNAT, DNAT-, REDIRECT, CONTINUE
#   or LOG.
#
#    ACCEPT   -- allow the connection request
#    DROP     -- ignore the request
#    REJECT   -- disallow the request and return an
#         icmp-unreachable or an RST packet.
#    DNAT     -- Forward the request to another
#         system (and optionally another
#         port).
#    DNAT-    -- Advanced users only.
#         Like DNAT but only generates the
#         DNAT iptables rule and not
#         the companion ACCEPT rule.
#    REDIRECT -- Redirect the request to a local
#         port on the firewall.
#    REDIRECT-
#      -- Advanced users only.
#         Like REDIRET but only generates the
#         REDIRECT iptables rule and not
#         the companion ACCEPT rule.
#    CONTINUE -- (For experts only). Do not process
#         any of the following rules for this
#         (source zone,destination zone). If
#         The source and/or destination IP
#         address falls into a zone defined
#         later in /etc/shorewall/zones, this
#         connection request will be passed
#         to the rules defined for that
#         (those) zone(s).
#    LOG      -- Simply log the packet and continue.
#
#   May optionally be followed by ":" and a syslog log
#   level (e.g, REJECT:info). This causes the packet to be
#   logged at the specified level.
#
#   You may also specify ULOG (must be in upper case) as a
#   log level.This will log to the ULOG target for routing
#   to a separate log through use of ulogd
#   (http://www.gnumonks.org/projects/ulogd).
#
# SOURCE  Source hosts to which the rule applies. May be a zone
#                       defined in /etc/shorewall/zones, $FW to indicate the
#   firewall itself, or "all" If the ACTION is DNAT or
#   REDIRECT, sub-zones of the specified zone may be
#   excluded from the rule by following the zone name with
#   "!' and a comma-separated list of sub-zone names.
#
#   Except when "all" is specified, clients may be further
#   restricted to a list of subnets and/or hosts by
#   appending ":" and a comma-separated list of subnets
#   and/or hosts. Hosts may be specified by IP or MAC
#   address; mac addresses must begin with "~" and must use
#   "-" as a separator.
#
#   dmz:192.168.2.2  Host 192.168.2.2 in the DMZ
#
#   net:155.186.235.0/24 Subnet 155.186.235.0/24 on the
#      Internet
#
#   loc:192.168.1.1,192.168.1.2
#      Hosts 192.168.1.1 and
#      192.168.1.2 in the local zone.
#   loc:~00-A0-C9-15-39-78  Host in the local zone with
#                                               MAC address 00:A0:C9:15:39:78.
#
#   Alternatively, clients may be specified by interface
#   by appending ":" to the zone name followed by the
#   interface name. For example, loc:eth1 specifies a
#   client that communicates with the firewall system
#   through eth1. This may be optionally followed by
#   another colon (":" ) and an IP/MAC/subnet address
#   as described above (e.g., loc:eth1:192.168.1.5).
#
# DEST  Location of Server. May be a zone defined in
#   /etc/shorewall/zones, $FW to indicate the firewall
#   itself or "all"
#
#   Except when "all" is specified, the server may be
#   further restricted to a particular subnet, host or
#   interface by appending ":" and the subnet, host or
#   interface. See above.
#
#    Restrictions:
#
#    1. MAC addresses are not allowed.
#    2. In DNAT rules, only IP addresses are
#       allowed; no FQDNs or subnet addresses
#       are permitted.
#    3. You may not specify both an interface and
#       an address.
#
#   Unlike in the SOURCE column, you may specify a range of
#   up to 256 IP addresses using the syntax
#   <first ip>-<last ip>. When the ACTION is DNAT or DNAT-,
#   the connections will be assigned to addresses in the
#   range in a round-robin fashion.
#
#   The port that the server is listening on may be
#   included and separated from the server's IP address by
#   ":". If omitted, the firewall will not modifiy the
#   destination port. A destination port may only be
#   included if the ACTION is DNAT or REDIRECT.
#
#   Example: loc:192.168.1.3:3128 specifies a local
#   server at IP address 192.168.1.3 and listening on port
#   3128. The port number MUST be specified as an integer
#   and not as a name from /etc/services.
#
#   if the ACTION is REDIRECT, this column needs only to
#   contain the port number on the firewall that the
#   request should be redirected to.
#
# PROTO  Protocol - Must be "tcp", "udp", "icmp", a number, or
#   "all".
#
# DEST PORT(S)    Destination Ports. A comma-separated list of Port
#   names (from /etc/services), port numbers or port
#   ranges; if the protocol is "icmp", this column is
#   interpreted as the destination icmp-type(s).
#
#   A port range is expressed as <low port>:<high port>.
#
#   This column is ignored if PROTOCOL = all but must be
#   entered if any of the following ields are supplied.
#   In that case, it is suggested that this field contain
#    "-"
#
#   If your kernel contains multi-port match support, then
#   only a single Netfilter rule will be generated if in
#   this list and the CLIENT PORT(S) list below:
#   1. There are 15 or less ports listed.
#   2. No port ranges are included.
#   Otherwise, a separate rule will be generated for each
#   port.
#
# CLIENT PORT(S) (Optional) Port(s) used by the client. If omitted,
#   any source port is acceptable. Specified as a comma-
#   separated list of port names, port numbers or port
#   ranges.
#
#   If you don't want to restrict client ports but need to
#   specify an ADDRESS in the next column, then place "-"
#   in this column.
#
#   If your kernel contains multi-port match support, then
#   only a single Netfilter rule will be generated if in
#   this list and the DEST PORT(S) list above:
#   1. There are 15 or less ports listed.
#   2. No port ranges are included.
#   Otherwise, a separate rule will be generated for each
#   port.
#
# ORIGINAL DEST (0ptional -- only allowed if ACTION is DNAT[-] or
#                       REDIRECT[-]) If included and different from the IP
#   address given in the SERVER column, this is an address
#   on some interface on the firewall and connections to
#   that address will be forwarded to the IP and port
#   specified in the DEST column.
#
#   A comma-separated list of addresses may also be used.  
#   This is usually most useful with the REDIRECT target  
#   where you want to redirect traffic destined for
#   particular set of hosts.
#
#   Finally, if the list of addresses begins with "!" then
#   the rule will be followed only if the original  
#   destination address in the connection request does not
#   match any of the addresses listed.
#
#   The address (list) may optionally be followed by
#   a colon (":" ) and a second IP address. This causes
#   Shorewall to use the second IP address as the source
#   address in forwarded packets. See the Shorewall
#   documentation for restrictions concerning this feature.
#   If no source IP address is given, the original source
#   address is not altered.
#
# Example: Accept SMTP requests from the DMZ to the internet
#
# #ACTION SOURCE DEST PROTO DEST    SOURCE ORIGINAL
# #                               PORT    PORT(S) DEST
# ACCEPT dmz net   tcp smtp
#
# Example: Forward all ssh and http connection requests from the internet
#   to local system 192.168.1.3
#
# #ACTION SOURCE DEST            PROTO DEST    SOURCE ORIGINAL
# #                                       PORT    PORT(S) DEST
# DNAT net loc:192.168.1.3 tcp ssh,http
#
# Example: Redirect all locally-originating www connection requests to
#   port 3128 on the firewall (Squid running on the firewall
#   system) except when the destination address is 192.168.2.2
#
# #ACTION  SOURCE DEST      PROTO DEST    SOURCE ORIGINAL
# #                               PORT    PORT(S) DEST
# REDIRECT loc 3128      tcp www  - !192.168.2.2
#
# Example: All http requests from the internet to address
#                130.252.100.69 are to be forwarded to 192.168.1.3
#
# #ACTION  SOURCE DEST       PROTO DEST    SOURCE ORIGINAL
# #                                PORT    PORT(S) DEST
# DNAT      net loc:192.168.1.3 tcp     80      -       130.252.100.69
#
#       Example: You want to accept SSH connections to your firewall only  
#   from internet IP addresses 130.252.100.69 and 130.252.100.70
#
# #ACTION  SOURCE DEST       PROTO DEST    SOURCE ORIGINAL
# #                                PORT    PORT(S) DEST
# ACCEPT  net:130.252.100.69,130.252.100.70 \
#     tcp 22
##############################################################################
#ACTION  SOURCE  DEST       PROTO DEST    SOURCE    ORIGINAL
#                                 PORT    PORT(S)    DEST
ACCEPT masq fw tcp domain,bootps,http,https,631,imap,pop3,smtp,nntp,ntp -
ACCEPT masq fw udp domain,bootps,http,https,631,imap,pop3,smtp,nntp,ntp -
ACCEPT fw masq tcp 631,515,137,138,139 -
ACCEPT fw masq udp 631,515,137,138,139 -
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
 
 
 
/etc/shorewall/policy :
 
#
# Shorewall 1.4 -- Policy File
#
# /etc/shorewall/policy
#
# This file determines what to do with a new connection request if we
# don't get a match from the /etc/shorewall/rules file or from the
# /etc/shorewall/common[.def] file. For each source/destination pair, the
# file is processed in order until a match is found ("all" will match
# any client or server).
#
# Columns are:
#
# SOURCE  Source zone. Must be the name of a zone defined
#   in /etc/shorewall/zones, $FW or "all".
#
# DEST  Destination zone. Must be the name of a zone defined
#   in /etc/shorewall/zones, $FW or "all"
#
#  WARNING: Firewall->Firewall policies are not allowed; if
#    you have a policy where both SOURCE and DEST are $FW,
#    Shorewall will not start!
#
# POLICY  Policy if no match from the rules file is found. Must
#   be "ACCEPT", "DROP", "REJECT", "CONTINUE" or "NONE".
#
#   ACCEPT  - Accept the connection
#   DROP  - Ignore the connection request
#   REJECT  - For TCP, send RST. For all other, send
#       "port unreachable" ICMP.
#   CONTINUE - Pass the connection request past
#       any other rules that it might also
#       match (where the source or destination
#       zone in those rules is a superset of
#       the SOURCE or DEST in this policy).
#   NONE  - Assume that there will never be any
#       packets from this SOURCE
#       to this DEST. Shorewall will not set up
#       any infrastructure to handle such
#        packets and you may not have any rules
#       with this SOURCE and DEST in the
#       /etc/shorewall/rules file. If such a
#       packet _is_ received, the result is
#       undefined.
#
# LOG LEVEL If supplied, each connection handled under the default
#   POLICY is logged at that level. If not supplied, no
#   log message is generated. See syslog.conf(5) for a
#   description of log levels.
#
#   Beginning with Shorewall version 1.3.12, you may
#   also specify ULOG (must be in upper case). This will
#   log to the ULOG target and sent to a separate log
#   through use of ulogd
#   (http://www.gnumonks.org/projects/ulogd).
#
#   If you don't want to log but need to specify the
#   following column, place "_" here.
#
# LIMIT:BURST If passed, specifies the maximum TCP connection rate
#   and the size of an acceptable burst. If not specified,
#   TCP connections are not limited.
#
# As shipped, the default policies are:
#
# a) All connections from the local network to the internet are allowed
# b) All connections from the internet are ignored but logged at syslog
#    level KERNEL.INFO.
# d) All other connection requests are rejected and logged at level
#    KERNEL.INFO.
###############################################################################
#SOURCE  DEST  POLICY  LOG LEVEL LIMIT:BURST
masq net ACCEPT
loc net ACCEPT
fw net ACCEPT
net all DROP info
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
 


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 14-04-2004 à 22:43:44    

ça n'a pas l'air d'être lié au firewall n'est-ce pas?


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 15-04-2004 à 12:51:54    

je relance


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 16-04-2004 à 09:32:18    

rien à faire???


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 16-04-2004 à 10:40:18    

J'ai regardé vite fait ton topic et un truc m'a interpellé.
 
J'utilise shorewall comme FW et pour activer le masquerading (pour fair un partage de connexion) je n'utilise pas du tout le fichier rules mais plutot le fichier masq (je me souviens plus exactement du nom) dans lequel tu indiques un truc du genre  
 
eth0    eth1
 
si eth0 est ton modem sagem et eth1 ton interface ethernet.
 
Ensuite le fichier rules ne doit contenir que les execeptions au fichier policy (en général tu fermes tout ds les policy et tu ouvres ce qui est nécessaire ds rules).
 
J'espère que ça t'a aidé.

Reply

Marsh Posté le 16-04-2004 à 10:41:34    

Un dernier point, l'interface graphique de MDK pour shorewall n'est pas terrible, je te conseille de ne pas l'utiliser et de bricoler les 4 ou 5 fichiers de /etc/shorewall/ qui sont utiles.

Reply

Marsh Posté le 16-04-2004 à 12:58:22    

Mais si je désactive complétement le firewall ça devrait marcher dans tous les cas, non? (ce qui n'est pas le cas)


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 16-04-2004 à 13:35:39    

felix007 a écrit :

Mais si je désactive complétement le firewall ça devrait marcher dans tous les cas, non? (ce qui n'est pas le cas)


 
nan le masquerading, avec shorewall, nécessite un shorewall actif (shorewall (re)start).
 
En lisant la dic du site shorewall en gros tu en as pour 5 min à faire ka conf de ton FW avec les fichiers textes. C'est extrèmement simple.

Reply

Marsh Posté le 16-04-2004 à 13:40:13    

Disons qu'il faut bien comprendre certains points :
 
shorewall arrêté (shorewall stop) coupe toute les connexions donc rien ne rentre/sort
shorewall désactivé (shorewall clear) vide toute les règles iptables ainsi que le masquerading donc tout rentre/sort mais pas de conf masq
 
Donc, je connais plus trop MDK mais je pense qu'il faut le désactiver à partir de l'interface MDK et ensuite bricoler les fichiers de conf.

Reply

Marsh Posté le 16-04-2004 à 18:38:14    

merci beaucoup je vais me regarder ce que tu dis


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 21-04-2004 à 13:07:45    

ça ne marche toujours pas.
 
J'ai l'impression que ce doit être bcp plus simple.
Je réexplique ma question,
 
Une fois que j'ai installé ma connexion internet via USB, que dois-je faire exactement pour installer la connexion réseau sans annuler la connexion internet, puis partager la connexion internet avec tout le réseau??????????


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 21-04-2004 à 18:47:34    

je relance


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 21-04-2004 à 19:25:54    

Pour le problème lié au modem, tu as demandé sur le forum de ce site : http://www.eagle-usb.org/ ?
Quand j'avais eu des problèmes avec mon fast 800 et ma mandrake 9.2, ils m'avaient aidé à résoudre le problème très efficacement.

Reply

Marsh Posté le 21-04-2004 à 19:35:32    

Je vais poser la question


---------------
Pingouin un jour, Pingouin... ?
Reply

Marsh Posté le 14-11-2004 à 18:50:25    

et donc pour activer le partage de connexion dans shorewall ?
 
j'ai mis  
 
 
ppp0 eth0  dans /etc/shorewall/masq
 
mais j'ai ca quand je l'allume :
 

Citation :

Masqueraded Networks and Hosts:
   Error: Unknown interface ppp0


 
ifconfig :

Citation :

eth0      Lien encap:Ethernet  HWaddr 00:0F:1F:25:E5:65
          inet adr:192.168.0.1  Bcast:192.168.0.255  Masque:255.255.255.0
          adr inet6: fe80::20f:1fff:fe25:e565/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3208 errors:0 dropped:0 overruns:0 frame:0
          TX packets:619 errors:0 dropped:0 overruns:0 carrier:4
          collisions:0 lg file transmission:1000
          RX bytes:231322 (225.9 Kb)  TX bytes:238094 (232.5 Kb)
          Interruption:11
 
eth2      Lien encap:Ethernet  HWaddr 00:60:4C:0C:FF:66
          adr inet6: fe80::260:4cff:fe0c:ff66/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:65535  Metric:1
          RX packets:157223 errors:0 dropped:0 overruns:0 frame:0
          TX packets:198034 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:41746228 (39.8 Mb)  TX bytes:67586774 (64.4 Mb)
 
lo        Lien encap:Boucle locale
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4089 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4089 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:182170 (177.9 Kb)  TX bytes:182170 (177.9 Kb)
 
ppp0      Lien encap:Protocole Point-à-Point
          inet adr:82.xx.x.xx  P-t-P:192.168.254.254  Masque:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:157077 errors:0 dropped:0 overruns:0 frame:0
          TX packets:198010 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:3
          RX bytes:41425343 (39.5 Mb)  TX bytes:63625484 (60.6 Mb)

Reply

Marsh Posté le 14-11-2004 à 18:55:17    

en fait il fallait mettre ppp+ eth0.
Apparemment ca marche.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed