HI, sorry wenn ich mich nun nireissen lasse und völlig verzweifelt hier meine Frage stelle, aber ich bin an einem Punkt angekommen, an dem ich nicht mehr so recht weiter weiss. Sicherheitshalber hab' ich mir erlaubt in den Betreff schon mal PAM einzubauen ... ;-) Also: Ich habe ein kleines Netzwerkchen aus 5 Rechnern. Zum leichteren Verständnis hab' ich Sie für mich 192.168.10.10, 192.168.10.20 ... 192.168.10.50 getauft. Im Rechner, an dem ich sitze ist eine weitere NIC (eth0) für den DSL-Anschluß 'drinnen. Der Karte hab' ich die Adresse 192.168.0.1 gegeben. Wenn ich nun vom Rechner 192.168.10.10 via dsl ins internet gehen will klappt dies auch recht gut, aber! Früher mit ISDN war's ja noch einfach, da hatte ich als default Gateway für die anderen Rechner einfach die 192.168.10.10 angegeben, das klappte recht gut, nun aber mit dsl will die ganze sache nicht mehr. Vielleicht hat ja einer einen entscheidenden tip für mich und im Zweifelsfrage haut mir einfach PAM ... ;-) Gerne auch per PM, falls die "Anfängerfrage" hier stört. cu, BC -- Michael Nausch Anzinger Str. 20 85586 Poing +49-8121-971940 (voice) +49-8121-971941 (fax) http://omni128.de michael@nausch.org
* Montag, 20. August 2001 um 23:14 (+0200) schrieb Michael Nausch:
Im Rechner, an dem ich sitze ist eine weitere NIC (eth0) für den DSL-Anschluß 'drinnen. Der Karte hab' ich die Adresse 192.168.0.1 gegeben. Wenn ich nun vom Rechner 192.168.10.10 via dsl ins internet gehen will klappt dies auch recht gut, aber!
Früher mit ISDN war's ja noch einfach, da hatte ich als default Gateway für die anderen Rechner einfach die 192.168.10.10 angegeben, das klappte recht gut, nun aber mit dsl will die ganze sache nicht mehr.
Was genau will denn nicht mehr? Ausser dem Netzwerk-Interface (pppX statt ipppX) und dem erforderlichen MSS-Clamping hat sich bei DSL im Prinzip nichts geändert. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Griasde Bua! Bereits am Dienstag 21 August 2001 00:37 schrieb Andreas Koenecke: Sorry, daß ich mich erst jetzt melde, aber ich hatte die Tage einiges um die Ohren ...
Was genau will denn nicht mehr? Ausser dem Netzwerk-Interface (pppX statt ipppX) und dem erforderlichen MSS-Clamping hat sich bei DSL im Prinzip nichts geändert.
MSS-Clamping? Ui, das ist neu, was ist denn das? ;-) O.K. also nochmals ganz von vorne: | | | <----- Verbindung zum Internet | über DSL-Modem zu | t-longline | +-----+-----+ | eth0 | | | +-----+ | eth1 +--------------+ Hub | | | +-+-+-+ | "Server" | | | +-----------+ | | | | +-----------+ | | | | | | | | | | | eth0 +----------------+ | | | | | "clientA" | | +-----------+ | | +-----------+ | | | | | | | | eth0 +------------------+ | | | "clientB" | +-----------+ Folgende IP-Adressen hab' ich vergeben: Server: eth0 IP-Adresse : 192.168.0.1 netmask : 255.255.255.0 default-GW : 192.168.0.99 eth1 IP-Adresse : 192.168.10.10 netmask : 255.255.255.0 default-GW : 192.168.0.99 clientA: eth0 IP-Adresse : 192.168.10.20 netmask : 255.255.255.0 default-GW : 192.168.10.10 clientB: eth0 IP-Adresse : 192.168.10.30 netmask : 255.255.255.0 default-GW : 192.168.10.10 Derzeit läuft der "Server" (auf dem auch Samba zwecks WINxx-Zugriffe werkel) im stand-alone-Betrieb, daich erst einmal den DSL-Anschluß fertig einrichten wollte, sowie meine eigene firewall verwenden wollte. Klappt alles sehr gut. Nur wenn ich nun den Rest der Familie auch noch an's Netz hängen will, die Frau meckert schon, da sich nicht mehr surfen kann ;-), dann geht's so richtig los. Für mich ist erst einmal wichtig, ob die ganze Adressvergabe und die Geschichte mit den Default-Gateways so richtig vergeben wurde. Hab' mir dieverse SuSE-Bücher gekauft, aber wenn ich die Dinger noch öfter durchlese, dann bin ich auch nocht nicht recht viel schlauer geworden. Andreas, erst einmal die Frage passt's soweit. Wenn ja, dann macht'S Sinn weiter zumachen. Wenn nein, dann klär' mich bitte auf oder PAM! ;-)) Aber danke schon mal für Deine oder auch jede andere Unterstützung! Pfiadseichallemidananda! BC -- Michael Nausch Anzinger Str. 20 85586 Poing +49-8121-971940 (voice) +49-8121-971941 (fax) http://omni128.de michael@nausch.org
* Montag, 27. August 2001 um 21:24 (+0200) schrieb Michael Nausch:
MSS-Clamping?
Ui, das ist neu, was ist denn das? ;-)
Wegen der der unterschiedlichen MTU des ppp-Interfaces ppp0 des Routers und der Ethernet-Interfaces ethX der Clients und sonstiger, noch nicht geklärter Probleme, muss für ein funktionierendes Routing/Masquerading "getrickst" werden: Entweder muss auf den Clients die MTU der Netzwerk-Interfaces an die MTU des ppp-Interfaces (1492) angepasst werden *oder* auf dem Router wird "MSS-Clamping" gemacht. Beim "MSS-Clamping" wird in allen ausgehenden Paketen die MSS (Maximum Segment Size = Größte "Nutzlast", also reine Daten ohne Header) so gesetzt, dass Antwort-Pakete auf dem Router bzw. dem 1. Hop nicht fragmentiert werden müssen. Zum MSS-Clamping gibt es je nach PPPoE- und Kernel-Version verschiedene Möglichkeiten.
O.K. also nochmals ganz von vorne: [ Beste ASCII-Grafik des Jahres ;-) ] Server: eth0 IP-Adresse : 192.168.0.1 netmask : 255.255.255.0 default-GW : 192.168.0.99
eth1 IP-Adresse : 192.168.10.10 netmask : 255.255.255.0 default-GW : 192.168.0.99
Eine Default-Route brauchst (darfst?) du auf dem Router nicht (zu) setzen. Das macht der pppd nach dem Verbindunsaufbau besser "automatisch"...
[ Client-Netzwerk-Konfiguration ]
Das sieht sehr gut aus.
Andreas, erst einmal die Frage passt's soweit. Wenn ja, dann macht'S Sinn weiter zumachen. Wenn nein, dann klär' mich bitte auf oder PAM! ;-))
Bis auf die Default-Route auf dem Router sieht das für mich bestens aus. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Habedieehreoidewuaschdhaud! Am Montag 27 August 2001 23:29 schrieb Andreas Koenecke:
Wegen der der unterschiedlichen MTU des ppp-Interfaces ppp0 des Routers und der Ethernet-Interfaces ethX der Clients und sonstiger, noch nicht geklärter Probleme, muss für ein funktionierendes Routing/Masquerading "getrickst" werden:
Hab' ich soweit verstanden. O.K. Klar.
Entweder muss auf den Clients die MTU der Netzwerk-Interfaces an die MTU des ppp-Interfaces (1492) angepasst werden *oder* auf dem Router wird "MSS-Clamping" gemacht.
Das einfachste wird IMHO wohl sein, den clients die kleinere MTU beizubringen, oder? Gibt es da unterschiede zwischen den WINxx- und den Linux-Clients bei der config?
Zum MSS-Clamping gibt es je nach PPPoE- und Kernel-Version verschiedene Möglichkeiten.
Verwende kernel 2.4.4 ("Eigenbau") da sonst mein USB-scanner nicht so will, wie ich ...
O.K. also nochmals ganz von vorne: [ Beste ASCII-Grafik des Jahres ;-) ]
Das hat ja auch ein wenig gedauert! ;-) Aber ich denke mal ein Bild sagt mehr als 1.000 Worte, zumal tu' ich mir dann auch leichter, wenn ich 'was erklären soll ... :-)
Eine Default-Route brauchst (darfst?) du auf dem Router nicht (zu) setzen. Das macht der pppd nach dem Verbindunsaufbau besser "automatisch"...
O.K. Hab' ich entfernt und klappt auch soweit ganz gut.
Bis auf die Default-Route auf dem Router sieht das für mich bestens aus.
Ist alles auch wunderbar eingetragen. So und nun zu Schritt zwei. Ich mache folgendes: 1. Ich beende die die T-DSL-Verbindung mittels adsl-stop, der Sicherheit wegen. 2. Ich beende meinen firewall.-script indem ich einfach alle Verbindungen wieder zulasse. 3. Ich starte einen client (WIN98) und schwups kann ich auf die SAMBA shared Verzeichnisse zugreifen. Internet ginge auch aber natürlich nicht jetzt gerade, weil ja adsl-stop noch "aktiv" ist. UND DANN. :-( 4. Ich starte meinen neuen firewall-script "gateway" und der schlägt entsprechend durch. Sprich dann geht gar nix mehr. Ich kann z.B. nicht t-lobgline anpingen, dader zugehörige Name nicht aufgelöst wird. Ich gehe mal davon aus, daß die Probleme, die ich mir selbst gebaut hab' nicht an der Netzwerkkonfiguration an sich liegen, sondern viel mehr an meinem firewall-script. Ich hab' das "corpus-delicti" hier mal abgedruckt. Sorry, wenn die Nachricht dadurch etwas groesser wird, aber ich denke, sonst ist die Unterstützung nur sehr schwierig machbar, oder? Also: #!/bin/tcsh # ========================================================= # Firewall-Skript fuer gatewayrechner im heimischen # Netzwerk bei Michael Nausch's server # --------------------------------------------------------- # Erste Version (V1.1) der Firewall # erste Gehversuche am 17.07.01 # zweiter Anlauf (V1.2) am 02.08.01 (Buch Seite 236 ff.) # - EXT device gaendert # dritter Anlauf (V1.3) am 05.08.01 # - modul ip_contrack_ftp.o geladen # vierte Version (V1.4) vom 19.08.01 # - for each - Schleife fuer die Mailserver eingetragen # ---------------------------------------------------------- # Neue Version (V2.0) der Firewall # erste Gehversuche am 19.08.01 # - Migration von "surfer" nach "gateway" # groesstenteils Uebernahme der Vorgaben aus dem Buch # Seite 246 ff. # echo "setting firewall rules for gateway (fw-mna)" # # ========================================================== # PART I: Variablen # ========================================================== set IPTABLES = /usr/sbin/iptables # ---------------------------------------------------------- # special ports set p_high = 1024:65535 # unprivileged ports set p_ssh = 1000:1023 # common ssh source ports # ---------------------------------------------------------- # interfaces set EXT = ppp0 set INT = eth1 set IF = ( $EXT $INT ) # ---------------------------------------------------------- # ip hosts set NS = ( 212.185.252.201 194.25.2.129 ) # t-longline NS set MS = ( 195.20.224.208 195.20.224.209 195.20.224.219 195.20.224.220 195.20.224.204 212.227.126.134 212.227.126.130 212.227.126.138 212.227.126.142 ) # POP3 und SMTP # Server bei # puretec.de set loghost = 192.168.10.10 # Syslog-client set INTERN = 192.168.10.0/255.255.255.0 # heimisches # Netzwerk # ========================================================== # PART II: Grundkonfiguration: absichern # ========================================================== # Kernel Module laden # ip_contrack_ftp depmod -a modprobe ip_conntrack_ftp modprobe ip_nat_ftp modprobe ip_conntrack modprobe ipt_MASQUERADE # dynamische Kernelparameter setzen echo "0" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/tcp_syncookies echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses echo "5" > /proc/sys/net/ipv4/icmp_destunreach_rate echo "5" > /proc/sys/net/ipv4/icmp_echoreply_rate echo "5" > /proc/sys/net/ipv4/icmp_paramprob_rate echo "10" > /proc/sys/net/ipv4/icmp_timeexceed_rate foreach if ($IF) echo "1" > /proc/sys/net/ipv4/conf/$if/rp_filter echo "0" > /proc/sys/net/ipv4/conf/$if/accept_redirects echo "0" > /proc/sys/net/ipv4/conf/$if/accept_source_route echo "0" > /proc/sys/net/ipv4/conf/$if/bootp_relay echo "1" > /proc/sys/net/ipv4/conf/$if/log_martians end # ---------------------------------------------------------- # Default Policy und flush $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT DROP $IPTABLES -F # flush aller chains (Tabelle filter) $IPTABLES -t nat -F # flush aller chains (Tabelle nat) $IPTABLES -X # delete all userdefined chains # (Tabelle filter) # ---------------------------------------------------------- # lokale Prozesse $IPTABLES -A OUTPUT -o lo -j ACCEPT $IPTABLES -A INPUT -i lo -j ACCEPT # ========================================================== # PART III: endgueltige Filterregeln # ========================================================== # ---------------------------------------------------------- # ssh fuer Fernwartung # wird derzeit nicht benoetigt, unter Umstaenden spaeter # einfuegen # ---------------------------------------------------------- # DROP & LOG Chain $IPTABLES -N my_drop $IPTABLES -A my_drop -p ICMP -j LOG --log-prefix "DROP-ICMP " $IPTABLES -A my_drop -p UDP -j LOG --log-prefix "DROP-UDP " $IPTABLES -A my_drop -p TCP -j LOG --log-prefix "DROP-TCP " $IPTABLES -A my_drop -j DROP # ========================================================== # PART IV: Masquerading, generell bestehende Verbindungen # ========================================================== # ---------------------------------------------------------- # MASQUERADING $IPTABLES -t nat -A POSTROUTING -o $EXT -j MASQUERADE echo "1" > /proc/sys/net/ipv4/ip_forward # wieder einschalten echo "1" > /proc/sys/net/ipv4/ip_dynaddr # ---------------------------------------------------------- # ausgehende Pakete bei bereits aufgebauter Verbindungen $IPTABLES -A OUTPUT \ -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $INT -o $EXT \ -m state --state ESTABLISHED,RELATED -j ACCEPT # ---------------------------------------------------------- # Rueckkanal: eingehende Pakete zu einer bestehenden Verbindung $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED \ -j ACCEPT $IPTABLES -A INPUT -m state --state NEW,INVALID -j my_drop $IPTABLES -A FORWARD -i $EXT -o $INT \ -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $EXT -o $INT \ -m state --state NEW,INVALID -j my_drop # ========================================================== # PART V: Filterregeln fuer lokale Dienste # ========================================================== # ---------------------------------------------------------- # ICMP # ping: 8 und 0, ausgehend $IPTABLES -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT # ---------------------------------------------------------- # SYSLOG # wird vorerst nicht verwendet # ========================================================== # PART VI: Filterregeln fuer Forwarding # ========================================================== # ---------------------------------------------------------- # ICMP $IPTABLES -A FORWARD -o $EXT \ -p ICMP --icmp-type echo-reply -j ACCEPT # $IPTABLES -A INPUT -p ICMP --icmp-type echo-request -j my_drop # # source squench (4) # # $IPTABLES -A FORWARD -o $EXT -p ICMP --icmp-type source-quench -j ACCEPT # $IPTABLES -A INPUT -p ICMP --icmp-type source-quench -j my_drop # # time exceeded (11) unkritisch, daher freigeschaltet # # $IPTABLES -A FORWARD -o $EXT -p ICMP --icmp-type time-exceeded -j ACCEPT # $IPTABLES -A INPUT -p ICMP --icmp-type time-exceeded -j ACCEPT # # parameter problem (12) unkritisch, daher freigeschaltet # # $IPTABLES -A FORWARD -o $EXT -p ICMP --icmp-type parameter-problem -j ACCEPT # $IPTABLES -A INPUT -p ICMP --icmp-type parameter-problem -j ACCEPT # # destination unreachable (3) # # $IPTABLES -A FORWARD -o $EXT -p ICMP --icmp-type fragmentation-needed -j ACCEPT # # $IPTABLES -A INPUT -p ICMP --icmp-type fragmentation-needed -j ACCEPT # $IPTABLES -A INPUT -p ICMP --icmp-type destination-unreachable -j ACCEPT # # ---------------------------------------------------------- # DNS foreach ns ( $NS ) $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p UDP --sport $p_high -d $ns --dport domain \ -j ACCEPT $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $ns --dport domain \ -j ACCEPT end # ---------------------------------------------------------- # SMTP, POP3 foreach ms ( $MS ) $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $ms --dport smtp \ -j ACCEPT $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $ms --dport pop3 \ -j ACCEPT end # ---------------------------------------------------------- # HTTP $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high --dport http -j ACCEPT # ---------------------------------------------------------- # HTTP via SSL $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high --dport https -j ACCEPT # ---------------------------------------------------------- # ident: reject $IPTABLES -A FORWARD -i $EXT -p TCP --dport auth --syn -j REJECT # ---------------------------------------------------------- # ftp, out, control connection $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high --dport ftp -j ACCEPT # $IPTABLES -A OUTPUT -p TCP --sport $p_high --dport ftp -j ACCEPT # $IPTABLES -A INPUT -p TCP --sport $p_high --dport ftp ! --syn -j ACCEPT # ---------------------------------------------------------- # Ausputzer: Rest sperren, loggen $IPTABLES -A INPUT -j my_drop $IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j REJECT echo "done (firewall rules active!)" Alles klar? Bei mir leider nicht. Bei meinem firewall-script für einen stand-alone Rechner hab'Ä ich alles soweit inhaltlich verstanden und ich bin auch etwas ehrlich, daß ich es geschafft habe, das Ding zum Laufen zu kriegen. D'rum nervt es mich umsomehr, da ich nicht mehr weiter weis, warum das schnöde Ding jetzt nicht funktionieren will. Andreas glaube mir, ich hab, das SuSE-Firewallbuch jetzt schon zum 3ten oder 4ten male durchgelesen und verdaut, aber ich trete scheinbar immer nur auf einer Stelle. :-( Vielleicht hast Du ja den entscheidenden Tip für mich, bitteeeeeeeeeeeeeeeee ;-) Pfiade, BC -- Michael Nausch Anzinger Str. 20 85586 Poing +49-8121-971940 (voice) +49-8121-971941 (fax) http://omni128.de michael@nausch.org
* Dienstag, 28. August 2001 um 20:44 (+0200) schrieb Michael Nausch:
Habedieehreoidewuaschdhaud!
"brain: Habedieehreoidewuaschdhaud!: word not found, Reboot? <y>" ;-)
[ MSS-Clamping ] Das einfachste wird IMHO wohl sein, den clients die kleinere MTU beizubringen, oder?
Kann man machen, aber ich finde es einfacher mit 'iptables' auf dem Router (s.u.)
So und nun zu Schritt zwei. Ich mache folgendes:
UND DANN. :-(
4. Ich starte meinen neuen firewall-script "gateway" und der schlägt entsprechend durch. Sprich dann geht gar nix mehr.
Um die Samba-Shares des Routers zu nutzen, musst du aber auch noch die Ports 137,138,139(?) auf dem Router "öffnen" (für Zugriffe aus dem lokalen Netz).
Ich kann z.B. nicht t-lobgline anpingen, dader zugehörige Name nicht aufgelöst wird.
'adsl-start' ist aber ausgeführt und der Router hat die Verbindung aufgebaut? Und -- hm, ich traue mich kaum zu fragen, aber... -- die T-Online-NS sind auf den *Clients* eingetragen? <duck> Ein (potentielles) Problem könnten die Regeln für die NS sein: Laut RFC müssen IIRC NS-Anfragen nicht unbedingt von den $HIGHPORTS ausgehen, auch Anfragen _von_ Port 53 sind erlaubt.
# ---------------------------------------------------------- # MASQUERADING
$IPTABLES -t nat -A POSTROUTING -o $EXT -j MASQUERADE
Hier z.B. für "MSS-Clamping" einfügen: $IPTABLES -A FORWARD -p tcp -i $INT -o $EXT -s $LAN --tcp-flags\ SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# ---------------------------------------------------------- # ICMP
$IPTABLES -A FORWARD -o $EXT \ -p ICMP --icmp-type echo-reply -j ACCEPT
Wenn du von den Clients pingen willst, dann müsste da oben stehen: "--icmp-type echo-request", oder?
$IPTABLES -A INPUT -j my_drop $IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j REJECT
Warum lässt du die "übriggebliebenen" Pakete der OUTPUT-Chain vor dem "rejecten" nicht auch noch durch 'my-drop' laufen? Also ich finde, das Firewall-Skript sieht sehr gut aus. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Griasde! Am Dienstag 28 August 2001 23:51 schrieb Andreas Koenecke:
Um die Samba-Shares des Routers zu nutzen, musst du aber auch noch die Ports 137,138,139(?) auf dem Router "öffnen" (für Zugriffe aus dem lokalen Netz).
137 und 138 gehören nmbd und 139 smbd. 'ne FRage am Rand, ist das dann TCP-Verkehr, wahrscheinlich schon oder, oder ist es besser, den Port generell freizugeben. natürlich nur für das interen Netzwerk.
Und -- hm, ich traue mich kaum zu fragen, aber... -- die T-Online-NS sind auf den *Clients* eingetragen? <duck>
Sind z.B. hier auf dem Rechner, an dem ich sitze, das ist der Router/server in der resolv.conf eingetragen. Starte ich meinen firewall-standalone-pc script, dann geht's ja auch .. :-(
Ein (potentielles) Problem könnten die Regeln für die NS sein: Laut RFC müssen IIRC NS-Anfragen nicht unbedingt von den $HIGHPORTS ausgehen, auch Anfragen _von_ Port 53 sind erlaubt.
Hmmm, versteh' ich zwar (jetzt noch) nicht aber das kann ja noch werden ...
Hier z.B. für "MSS-Clamping" einfügen: $IPTABLES -A FORWARD -p tcp -i $INT -o $EXT -s $LAN --tcp-flags\ SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Für meinen script müsste es aber wahrscheinlich dann heißen: $IPTABLES -A FORWARD -p tcp -i $INT -o $EXT -s $INTERN ... oder? m;-)
# ---------------------------------------------------------- # ICMP
$IPTABLES -A FORWARD -o $EXT \ -p ICMP --icmp-type echo-reply -j ACCEPT
Wenn du von den Clients pingen willst, dann müsste da oben stehen: "--icmp-type echo-request", oder?
Jep, glaub' da hast Du recht ...
$IPTABLES -A INPUT -j my_drop $IPTABLES -A FORWARD -j my_drop $IPTABLES -A OUTPUT -j REJECT
Warum lässt du die "übriggebliebenen" Pakete der OUTPUT-Chain vor dem "rejecten" nicht auch noch durch 'my-drop' laufen?
Ui, da ist mir doch glatt 'was von meiner firewall-standalone durchgerutscht. Danke!
Also ich finde, das Firewall-Skript sieht sehr gut aus.
Aber wahrscheinlich zu gut, denn es geht mit dem Teil weder was raus noch rein! Was nun sprach Zeus? Pfiade, BC -- Michael Nausch Anzinger Str. 20 85586 Poing +49-8121-971940 (voice) +49-8121-971941 (fax) http://omni128.de michael@nausch.org
* Mittwoch, 29. August 2001 um 21:47 (+0200) schrieb Michael Nausch:
137 und 138 gehören nmbd und 139 smbd. 'ne FRage am Rand, ist das dann TCP-Verkehr, wahrscheinlich schon oder, oder ist es besser, den Port generell freizugeben. natürlich nur für das interen Netzwerk.
AFAIK reicht TCP.
Sind z.B. hier auf dem Rechner, an dem ich sitze, das ist der Router/server in der resolv.conf eingetragen. Starte ich meinen firewall-standalone-pc script, dann geht's ja auch .. :-(
*Patch* (Das war die Hand, die ich mir vor den Kopf geschlagen habe.) Ich habe dich gestern falsch verstanden. Ich habe gedacht, die Namensauflösung funktioniert nicht auf den *Clients*... Deshalb habe ich hauptsächlich auf die FORWARD-Chain geachtet und dabei übersehen, dass in deinem Skript ausgehende NS-Anfragen vom *Router* nicht erlaubt sind... Also musst du noch in die NS-Schleife noch die Regeln für die OUTPUT-Chain hinzufügen. Aber das hast du ja inzwischen selbst gelöst, wie ich in deinem anderen Posting gelesen habe...
Für meinen script müsste es aber wahrscheinlich dann heißen: $IPTABLES -A FORWARD -p tcp -i $INT -o $EXT -s $INTERN ... oder? m;-)
Yepp. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Griasde Andreas, also ich denke mal ich bin ein kleines Stückchen näher an der Lösung! ;-) Also in meinem eigentlichen firewall-script hab' ich für den DNS folgendes eingetragen: # DNS foreach ns ( $NS ) $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p UDP --sport $p_high -d $ns --dport domain \ -j ACCEPT $IPTABLES -A FORWARD -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $ns --dport domain \ -j ACCEPT end Damit gehen keine DNS-Anfragen von dem Rechner an dem ich sitze, das ist der Router/server in meinem Netzwerkchen. Ändere ich das nun ab in: # DNS foreach ns ( $NS ) $IPTABLES -A OUTPUT -o $EXT -m state --state NEW \ -p UDP --sport $p_high -d $ns --dport domain \ -j ACCEPT $IPTABLES -A OUTPUT -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $ns --dport domain \ -j ACCEPT end Kann ich DNS-Anfragen machen. sprich t-longline anpingen. Also sag' ich mir mit dem Target MASQUERADE haut da 'was nicht so hin, wie es eigentlich soll, oder? Könnte es sein, daß es an dem Kernel-Modul iptable_nat liegt, ich hab' das nun mal explizit noch dazu geladen und siehe da, der ping zu t-online geht nun auch mit der "richtigen" DNS-Regel! :-) Mal sehen, ob und wie der Rest nun funktioniert. Ich meld' mich dann gleich nochmals ... Pfiade, BC -- Michael Nausch Anzinger Str. 20 85586 Poing +49-8121-971940 (voice) +49-8121-971941 (fax) http://omni128.de michael@nausch.org
HI,
Könnte es sein, daß es an dem Kernel-Modul iptable_nat liegt, ich hab' das nun mal explizit noch dazu geladen und siehe da, der ping zu t-online geht nun auch mit der "richtigen" DNS-Regel! :-)
Irgendwie und doch nicht. Ich kann kurz nach Starten der firewall-regel t-longline anpingen. http oder smtp geht nicht. Versuche ich dann später nochmals einen ping, geht auch dieser nicht, da er den Namen nicht auflösen könne ... :-( Scheibenkleister! :-( cu, BC -- Michael Nausch Anzinger Str. 20 85586 Poing +49-8121-971940 (voice) +49-8121-971941 (fax) http://omni128.de michael@nausch.org
* Mittwoch, 29. August 2001 um 22:09 (+0200) schrieb Michael Nausch:
Ändere ich das nun ab in:
# DNS
foreach ns ( $NS ) $IPTABLES -A OUTPUT -o $EXT -m state --state NEW \ -p UDP --sport $p_high -d $ns --dport domain \ -j ACCEPT
$IPTABLES -A OUTPUT -o $EXT -m state --state NEW \ -p TCP --sport $p_high -d $ns --dport domain \ -j ACCEPT
end
Kann ich DNS-Anfragen machen. sprich t-longline anpingen.
Ist klar, siehe auch mein anderes Posting... Und für deine Clients brauchst du dassselbe für die FORWARD-Chains.
Also sag' ich mir mit dem Target MASQUERADE haut da 'was nicht so hin, wie es eigentlich soll, oder?
Nein, der Router wird ja gar nicht masqueraded, der hat ja eine offizielle IP. Es müssen nur die Clients masqueraded werden, oder anders ausgedrückt, alle Pakete, die durch die FORWARD-Chain gehen.
Könnte es sein, daß es an dem Kernel-Modul iptable_nat liegt, ich hab' das nun mal explizit noch dazu geladen und siehe da, der ping zu t-online geht nun auch mit der "richtigen" DNS-Regel! :-)
Das Modul 'iptable_nat' wird AFAIK für das Masquarading benötigt. Zur "richtigen" Regel noch mal: Richtig ist: Obige Regeln in der OUTPUT-Chain für die NS-Anfragen des Routers *und* obige Regeln in der FORWARD-Chain für NS-Anfragen der Clients. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Griasde! Am Mittwoch 29 August 2001 22:48 schrieb Andreas Koenecke:
Nein, der Router wird ja gar nicht masqueraded, der hat ja eine offizielle IP. Es müssen nur die Clients masqueraded werden, oder anders ausgedrückt, alle Pakete, die durch die FORWARD-Chain gehen.
Das heisst also im klartext. Ich Depp hab' den funktionierenden firewall-script, den ich auf dem Raouter verwedne, nicht durch einen MASQUERADE-Script ersetzen, sondern ERGÄNZEN müssen, oder?
Das Modul 'iptable_nat' wird AFAIK für das Masquarading benötigt. Zur "richtigen" Regel noch mal: Richtig ist: Obige Regeln in der OUTPUT-Chain für die NS-Anfragen des Routers *und* obige Regeln in der FORWARD-Chain für NS-Anfragen der Clients.
O.K., dann werd' ich hald mal den bestehenden script, den ich derzeit verwende. belassen und um die einzelnen FORWARD targets erweiteren. Nochmals zur Wiederholung ich sitze am Server/Router surfer da und die clients, die hinter dem Server sitzen müssen Masqueradeiert werden. Stimmt's nun so? :-) Pfiade, BC -- Michael Nausch Anzinger Str. 20 85586 Poing +49-8121-971940 (voice) +49-8121-971941 (fax) http://omni128.de michael@nausch.org
* Mittwoch, 29. August 2001 um 22:56 (+0200) schrieb Michael Nausch:
Das heisst also im klartext. Ich Depp hab' den funktionierenden firewall-script, den ich auf dem Raouter verwedne, nicht durch einen MASQUERADE-Script ersetzen, sondern ERGÄNZEN müssen, oder?
Ja, genau so...
Nochmals zur Wiederholung ich sitze am Server/Router surfer da und die clients, die hinter dem Server sitzen müssen Masqueradeiert werden.
Stimmt's nun so? :-)
Ja! Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Tataeeee, hier ist die Pappnase des Monats! ;-) Ich galub' ich hab's, oder auch nicht ... ;-) Nochmals zum Verständnis: Konfiguration jetzt: | | | <----- Verbindung zum Internet | über DSL-Modem zu | t-longline | +-----+-----+ | eth0 | | | +---------+ | +--------------+ Drucker | | | +---------+ | "Server" | +-----------+ Hier ist beim firewall-script folgendes Regelkettenwerk zu beachten: + / \ / \ / \ +---------+ / \ | | incoming / \ | FORWARD | outgoing ---------->+ routing? +---->+ REGEL- +------------+--------> \ / | | ^ \ / +---------+ | \ / | \ / | \ / | + | | | | | V | +-------+-------+ +--------+-------+ | | | | | INPUT - REGEL | | OUTPUT - REGEL | | | | | +-------+-------+ +--------+-------+ | ^ | | V | LOKAL LOKAL Im Detail: INPUT-Regel : Es kommt ein Paket von ppp0 und das Paket wird an den "lokalen Rechner" weitergegeben. FORWARD-REGEL: Kommt nicht zum tragen, da das Routing im Firewall-script ausgeschaltet wurde. ( echo "0" > /proc/sys/net/ipv4/ip_forward ) OUTPUT-REGEL : Der Rechner verschickt selbst Pakete, die konform mit dieser Regel sein muss. (Den zugehörigen firewall-script findet man "weiter oben im thread".) Konfiguration jetzt: | | | <----- Verbindung zum Internet | über DSL-Modem zu | t-longline | +-----+-----+ | eth0 | | | +-----+ | eth1 +--------------+ Hub | | | +-+-+-+ | "Server" | | | +-----------+ | | | | +-----------+ | | | | | | | | | | | eth0 +----------------+ | | | | | "clientA" | | +-----------+ | | +-----------+ | | | | | | | | eth0 +------------------+ | | | "clientB" | +-----------+ Der "Server" bietet folgende Dienste: - SAMBA-Fileserver - Druckerserver - Router mit firewall mit DSL-Anschluss - voll funktionierende Workstation, d.h. ° Mailclient ° http, ftp ° Staroffice ° DTP (Sannen, gPhoto, Drucken ...) Wir ergänzen die Regelkette also mit Source-NAT (Masquerading): + / \ / \ / \ +---------+ / \ | | +---------+ incoming / \ | FORWARD | | POST- | outgoing ---------->+ routing? +--->+ REGEL- +--+--+ REGEL +----------> \ / | | ^ | S-NAT | \ / +---------+ | +---------+ \ / | \ / | \ / | + | | | | | V | +-------+-------+ +--------+-------+ | | | | | INPUT - REGEL | | OUTPUT - REGEL | | | | | +-------+-------+ +--------+-------+ | ^ | | V | LOKAL LOKAL Zusammengefasst nun also im Detail: Da auf dem "Server" auch noch nebenbei gearbeitet werden können muss, müssen die bekannten Regeln beibehalten werden: INPUT-Regel : Es kommt ein Paket von ppp0 und das Paket wird an den "lokalen Rechner" weitergegeben. FORWARD-REGEL: Es kommt ein Paket und wird an die FORWARD-REGEL weitergereicht, da das Routing im Firewall-script eingeschaltet wurde. ( echo "1" > /proc/sys/net/ipv4/ip_forward ) OUTPUT-REGEL : Der Rechner verschickt selbst Pakete, die konform mit dieser Regel sein muss. POST-REGEL : Im Firewall-Script wird "Masquerading" mittels ( $IPTABLES -t nat -A POSTROUTING -o $EXT -j MASQUERADE ) eingeschaltet; somit werden Pakete, die den Router via ppp0 verlassen maskiert, Die rückwärtige Richtung wird über das Kernel-Modul ip-conntrack automatisch Adressmäßig wieder umgeschrieben, so daß das Paket zum "verursachenden" Host zurückgeschickt wird. Zusätzliche muss für den SAMBA- und Printserver-Betrieb sichergestellt werden, daß die betreffenden Ports vom lokalen Netzwerk in Richtung Router/Server offen sind, aber von Richtung Internet aus, diese Port nicht erreichbar sind. So und dann sollte es auch mit den gewünschten Diensten am "Server/Router" klappen _U_N_D_ die clients im lokalen Netzwerk können auch surfen, mailen, speichern und drucken. Andreas, ich danke Dir nochmals für Deine aufopfernde Hilfe und wenn'S jemanden interessiert, dann bekommt er auch den firewall-script meiner beschriebenen Konfiguration; ggf. einfach melden .... Na denn, wie Meister Röhrich sagen würde "Na denn Prost ...!" Pfiadseichallemidananda! BC -- Michael Nausch Anzinger Str. 20 85586 Poing +49-8121-971940 (voice) +49-8121-971941 (fax) http://omni128.de michael@nausch.org
* Donnerstag, 30. August 2001 um 21:24 (+0200) schrieb Michael Nausch:
[ FAQ-werte Beschreibung der Netfilter-Ketten :-) ]
POST-REGEL : Im Firewall-Script wird "Masquerading" mittels ( $IPTABLES -t nat -A POSTROUTING -o $EXT -j MASQUERADE ) eingeschaltet; somit werden Pakete, die den Router via ppp0 verlassen maskiert, Die rückwärtige Richtung wird über das Kernel-Modul ip-conntrack automatisch Adressmäßig wieder umgeschrieben, so daß das Paket zum "verursachenden" Host zurückgeschickt wird.
Das soll jetzt keine Klugscheisserei sein, aber dein Beitrag ist zu gut, um hier eine Ungenauigkeit "durchzulassen": Für das Masquerading in *beide* Richtungen sind ausschliesslich die "nat"-Module zuständig. Mit den "conntrack"-Modulen können die Pakete "lediglich" auf die Zustände "NEW", "ESTABLISHED","RELATED" und "INVALID" geprüft werden.
Na denn, wie Meister Röhrich sagen würde "Na denn Prost ...!"
*Plopp* "Hau wech..." Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
participants (2)
-
Andreas Koenecke -
Michael Nausch