Hallo Liste,
ich hatte bis jetzt auf unseren Rechnern die Internet-Verbindung über einen Proxy (wwwoffle) realisiert, welcher auf dem Einwahl- server läuft. Damit auch ICQ funktioniert, will ich jetzt mit Masquerading arbeiten. Allerdings bin ich kurz davor daran zu verzweifeln. Am besten erst einmal meine Konfiguration(en)...
Client: -------------------------
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default hpnet.dresden.m 255.255.255.0 UG 1 0 0 eth0 localnet * 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo (hpnet ist unser Einwahlserver, seine IP ist 192.168.0.1)
+++
bash-2.04$ cat /etc/resolv.conf nameserver 217.237.159.1 nameserver 194.25.2.129
Server: --------------------------
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62.155.254.157 * 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default 62.155.254.157 0.0.0.0 UG 0 0 0 ppp0 (62.155.254.157 ist die dyn. IP, die der Provider bereitstellt)
+++
root@hpnet:/home/matthias# lsmod Module Size Used by iptable_filter 1696 0 (autoclean) (unused) ppp_deflate 40800 0 (autoclean) ppp_async 6224 0 (autoclean) ipt_MASQUERADE 1200 3 (autoclean) iptable_nat 13200 0 [ipt_MASQUERADE] ip_conntrack 13056 1 [ipt_MASQUERADE iptable_nat] ip_tables 10752 5 [iptable_filter ipt_MASQUERADE iptable_nat] ne2k-pci 5056 1 8390 6096 0 [ne2k-pci] bsd_comp 3984 0 ppp_generic 14896 0 [ppp_deflate ppp_async bsd_comp] slhc 4576 0 [ppp_generic] lcd 4096 0
+++
matthias@hpnet:~$ cat /etc/resolv.conf nameserver 217.237.159.1 nameserver 194.25.2.129
+++
Masquerading aktiviert durch:
root@hpnet:/home/matthias# iptables --flush root@hpnet:/home/matthias# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE root@hpnet:/home/matthias# echo "1" > /proc/sys/net/ipv4/ip_forward
-----------------------------------
Server: Kernel 2.4.17 Client: Kernel 2.4.9
Server und Client lassen sich untereinander anpingen. Externe Adressen (egal ob als IP oder Domainname) funktionieren nicht. Bei Linuxdoc.org gibt es ein wunderbares Howto zum Thema - ich kann aber bei meiner Konfiguration keinen Fehler finden. Hab ich irgendwas übersehen?
Viele Grüße & einen guten Rutsch,
Matthias
am Sun, dem 30.12.2001, um 12:07:08 +0100 mailte Matthias Petermann folgendes:
kann aber bei meiner Konfiguration keinen Fehler finden. Hab ich irgendwas übersehen?
Mmh, Fragen:
Ist es eine SuSE, wenn ja, läuft darauf die berühmt-berüchtigte SuSE-Firewall?
Kannst Du vom Zugangsrechner aus ins Internet?
Ansonsten: logge den Verkehr an INPUT und schaue, was da so ankommt. Ein 'iptables -L -v -n' zeigt, was so alles an Regeln existiert.
Andreas, Erfolg wünschend
Hallo Andreas,
vielen Dank für Deine Antwort.
On Sun, Dec 30, 2001 at 01:40:57PM +0100, Andreas Kretschmer wrote:
Ist es eine SuSE, wenn ja, läuft darauf die berühmt-berüchtigte SuSE-Firewall?
Nein, ist keine SuSE. Exakt läuft hier ein modernisiertes Slackware 4.x. Ich muss also alles per Hand einstellen, was bis jetzt auch kein Problem war.
Kannst Du vom Zugangsrechner aus ins Internet?
Ja, sowohl vom Server selbst als auch von den Clients über den Proxy.
Ansonsten: logge den Verkehr an INPUT und schaue, was da so ankommt. Ein 'iptables -L -v -n' zeigt, was so alles an Regeln existiert.
Bei "INPUT" und "OUTPUT" kann ich jeweils Traffic registrieren, der wird aber sehr wahrscheinlich nur von Telnet erzeugt, da der Server keinen Monitor+Keyboard hat. Bei "FORWARD" steht da eine Null - also wurde nichts weitergeleitet. Irgendwie vermute ich ein DNS-Problem, da auf dem Client bei z.B. "ping www.gmx.de" immer "unknown host" gemeldet wird. Auf dem Client habe ich in der /etc/resolv.conf die selben Nameserver eingetragen, die auch der Server fuer die Internet- Verbindung benutzt. Aber wie schon geschrieben - auch das direkte Angeben einer IP bringt eine ähnliche Meldung:
bash-2.04# ping 213.165.65.100 PING 213.165.65.100 (213.165.65.100): 56 data bytes ping: sendto: Network is unreachable ping: wrote 213.165.65.100 64 chars, ret=-1
Also: entweder der Client weiß nicht, wo er seine DNS-Anfragen senden soll oder das Masquerading funktioniert nicht.
Was ich vielleicht noch dazu schreiben sollte: Ich habe (vorerst) außer der Masquerading-Regel keine weiteren Regeln angelegt, da ich das Masq. erst einmal so zum Laufen bekommen wollte. In der HOWTO steht auch, dass diese minimale Form laufen sollte. Oder müssen notwendigerweise irgendwelche Forwarding-Regeln vorhanden sein, damit auch das Masq. läuft?
Viele Grüße,
Matthias
am Sun, dem 30.12.2001, um 15:14:46 +0100 mailte Matthias Petermann folgendes:
Was ich vielleicht noch dazu schreiben sollte: Ich habe (vorerst) außer der Masquerading-Regel keine weiteren Regeln angelegt, da ich das Masq. erst einmal so zum Laufen bekommen wollte. In der HOWTO steht auch, dass diese minimale Form laufen sollte. Oder müssen notwendigerweise irgendwelche Forwarding-Regeln vorhanden sein, damit auch das Masq. läuft?
IMHO nein.
Aber der Kernel muß ip-forward machen können, aber das hattest Du ja auch eingeschalten.
Andreas
Hallo,
On Sun, Dec 30, 2001 at 03:42:04PM +0100, Andreas Kretschmer wrote:
Aber der Kernel muß ip-forward machen können, aber das hattest Du ja auch eingeschalten.
Ja. Wobei das nur der Kernel des Servers machen muss, oder? Ich hab das dumme Gefühl, dass die Route am Client noch nicht stimmt. Irgendwie ist Masquerading eine verflixte Angelegenheit. Hab mich schon vor einem Jahr mal damit beschäftigt und als "Ausweg" einen Proxy eingesetzt. Das sieht in den Beschreibungen so super einfach aus - aber an irgendwas hängts noch. Dazu fällt mir ein - Tobias hatte doch mal einen Vortrag über NetFilter gemacht. Gibts den auch in einer Online-Version bzw. wird dort auch die Client-Konfiguration beschrieben?
Gruß,
Matthias
On Sun, Dec 30, 2001 at 07:17:53PM +0100, Matthias Petermann wrote:
Ja. Wobei das nur der Kernel des Servers machen muss, oder? Ich hab das dumme Gefühl, dass die Route am Client noch nicht stimmt.
Dann teste doch mal mit tcpdump, was zwischen client und server abgeht. Einfach Stück für Stück verfolgen bis wohin die Pakte flitzen. Alles andere ist Stochern im Nebel.
Reinhard
Hallo Reinhard,
erst einmal vielen Dank für Deine Mail. Tatsächlich kommen die Pakete nicht einmal beim Server an, weshalb ich auf die Route am Client tippen würde. Die Routing-Tabelle ist aber genau die, die ich in meinem ersten Posting gesendet habe. Kann es sein, dass beim Client nicht gleichzeitig "localnet" und "default" existieren dürfen?
Matthias
On Mon, Dec 31, 2001 at 12:42:46AM +0100, Reinhard Foerster wrote:
On Sun, Dec 30, 2001 at 07:17:53PM +0100, Matthias Petermann wrote:
Ja. Wobei das nur der Kernel des Servers machen muss, oder? Ich hab das dumme Gefühl, dass die Route am Client noch nicht stimmt.
Dann teste doch mal mit tcpdump, was zwischen client und server abgeht. Einfach Stück für Stück verfolgen bis wohin die Pakte flitzen. Alles andere ist Stochern im Nebel.
Reinhard
Lug-dd maillist - Lug-dd@schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
On Mon, Dec 31, 2001 at 08:54:05AM +0100, Matthias Petermann wrote:
erst einmal vielen Dank für Deine Mail. Tatsächlich kommen die Pakete nicht einmal beim Server an, weshalb ich auf die Route am Client tippen würde.
mmh.
Die Routing-Tabelle ist aber genau die, die ich in meinem ersten Posting gesendet habe. Kann es sein, dass beim Client nicht gleichzeitig "localnet" und "default" existieren dürfen?
Die müssen beide da sein. Bitte schicke mal den output von "ifconfig -an" und "netstat -nr" auf dem client. Vielleicht is ja dein 'localnet' müll.
Reinhard
Hallo!
Andreas Kretschmer wrote:
Was ich vielleicht noch dazu schreiben sollte: Ich habe (vorerst) außer der Masquerading-Regel keine weiteren Regeln angelegt, da ich das Masq. erst einmal so zum Laufen bekommen wollte.
Könntest Du mal genau diese Regeln mailen? Dort liegt IMHO das eigent- liche Problem. Ich hatte auch Probleme damit und habe dann die Regeln mit dem alten ipchains eingespielt.
Ein gutes Regelwerk für iptables würde mich auch interessieren. Wer kann helfen?
Gruss Reiner
On Mon, Dec 31, 2001 at 08:38:24AM +0100, Reiner Klaproth wrote:
Hallo!
Hallo Reiner,
Ein gutes Regelwerk für iptables würde mich auch interessieren. Wer kann helfen?
Für meinen Vortrag hatte ich die man-page zu iptables und die NAT-HOWTO von Rusty Russel verwendet. Da steht eigentlich alles wissenswerte drinn.
Ciao, Tobias
On Mon, Dec 31, 2001 at 08:38:24AM +0100, Reiner Klaproth wrote:
Könntest Du mal genau diese Regeln mailen? Dort liegt IMHO das eigent- liche Problem. Ich hatte auch Probleme damit und habe dann die Regeln mit dem alten ipchains eingespielt.
Hat er ja. Er sagte: root@hpnet:/home/matthias# iptables --flush root@hpnet:/home/matthias# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE root@hpnet:/home/matthias# echo "1" > /proc/sys/net/ipv4/ip_forward
Matthias: Dazu wäre nur anzumerken, daß der erste Befehl die nat-Tabelle NICHT löscht. Diese ist erst nach "iptables --flush -t nat" leer. Setze das also mal noch mit vorn in dein skript rein.
und dann poste mal alle Infos vom Server:
ifconfig -an netstat -nr iptables -vnL iptables -vnL -t nat
btw: Was ich gerade nicht kapiere: Wenn ich nach einer nat-Konfig wie oben angegeben eine Verbindung aufgebaut habe und dann auf dem nat-rechner ein "iptables -F -t nat" absetzte, kann ich zwar keine neuen nat-verbindungen machen, die alte geht aber weiterhin. Warum geht die alte Verbindung noch??? Wie verhindere ich, daß die alte Verbindung weiterhin funktionniert?
Reinhard (der sich bisher wenig mit iptables beschäftigt hat)
Hallo Reinhard,
Am Montag, dem 31. Dezember 2001 um 11:37:18, schrieb Reinhard Foerster:
Warum geht die alte Verbindung noch???
Der Kernel unterhaelt einen Cache zusammengehoerender Portnummern und IP-Adressen aehnlich dem ARP-Cache, damit auch die Antwortpakete richtig zugestellt werden koennen. Das bedeutet das alle Pakete, fuer die es einen Eintrag im Cache gibt, ganz anders behandelt werden.
Wie verhindere ich, daß die alte Verbindung weiterhin funktionniert?
echo 0 > /proc/sys/net/ipv4/ip_forward
oder vielleicht eine passende DROP-Regeln in der FORWARD-Chain?
Torsten
On Mon, Dec 31, 2001 at 02:24:21PM +0100, Torsten Werner wrote:
Warum geht die alte Verbindung noch???
Der Kernel unterhaelt einen Cache zusammengehoerender Portnummern und IP-Adressen aehnlich dem ARP-Cache, damit auch die Antwortpakete richtig zugestellt werden koennen.
Ja, das ist klar.
Das bedeutet das alle Pakete, fuer die es einen Eintrag im Cache gibt, ganz anders behandelt werden.
Mmh. Mit Entferen der Regel in der NAT-Tabelle könnte er im Cache die Einträge, die aufgrund der entfernten Regel erstellt worden sind, auch löschen oder notfalls den kompletten Cache löschen. Wenn er das nicht tut muß ich das per hand machen können.
Wie verhindere ich, daß die alte Verbindung weiterhin funktionniert?
echo 0 > /proc/sys/net/ipv4/ip_forward
nein, er soll ja weiter forwarden, nur nicht mehr NATten
oder vielleicht eine passende DROP-Regeln in der FORWARD-Chain?
Das heisst: Weil der Kern mit Paketen NAT macht, für die keine NAT-Regel mehr da ist, muß ich mir extra eine Regel einfallen lassen, um diese nicht mehr existierende Regel zu überstimmen. Wenn ich so eine Regel nicht finden würde müsste ich sicherheitshalber rebooten ... Das wäre totaler Unsinn, ist also ganz bestimmt nicht so.
Irgendwie muß sich also dieser NAT-Cache anzeigen und löschen lassen. Nur wie??? Wer weiss das? Im manual zu iptables steht nix dazu.
Anzeigen ging übrigens mit ipchains (ipchains -ML glaube ich, ich kanns im Moment nicht testen). Da standen dann immmer die timeout-werte mit dabei. Sowas muß es auch für iptables geben ...
Reinhard
On Mon Dec 31, 2001 at 16:14:55 +0100, Reinhard Foerster wrote:
Irgendwie muß sich also dieser NAT-Cache anzeigen
$ cat /proc/net/ip_conntrack
und löschen lassen.
Evtl. echo <kleine Zahl aka 0> > /proc/sys/net/ipv4/ip_conntrack_max
oder auch rmmod ip_conntrack + Konsorten
Ausprobieren mag ich das jetzt allerdings nicht... ;)
Adam
On Mon, Dec 31, 2001 at 06:05:46PM +0100, Adam Lackorzynski wrote:
On Mon Dec 31, 2001 at 16:14:55 +0100, Reinhard Foerster wrote:
Irgendwie muß sich also dieser NAT-Cache anzeigen
$ cat /proc/net/ip_conntrack
Das sind alle möglichen Verbindungen drin, nicht dur die genatteten.
Evtl. echo <kleine Zahl aka 0> > /proc/sys/net/ipv4/ip_conntrack_max
oder auch rmmod ip_conntrack + Konsorten
Das connection tracking hat mit nat erstmal nicht zu tun. Die Tabelle muß woanders stehen. Ich hab mal in den News gefragt, vielleicht findet sich da eine Antwort.
Reinhard
On Mon Dec 31, 2001 at 19:15:17 +0100, Reinhard Foerster wrote:
On Mon, Dec 31, 2001 at 06:05:46PM +0100, Adam Lackorzynski wrote:
$ cat /proc/net/ip_conntrack
Das sind alle möglichen Verbindungen drin, nicht dur die genatteten.
ACK.
Das connection tracking hat mit nat erstmal nicht zu tun. Die Tabelle muß woanders stehen. Ich hab mal in den News gefragt, vielleicht findet sich da eine Antwort.
http://netfilter.samba.org/unreliable-guides/netfilter-hacking-HOWTO/netfilt...:
4.3 Understanding NAT
[...]
NAT is separated into connection tracking (which doesn't manipulate packets at all), and the NAT code itself. Connection tracking is also designed to be used by an iptables modules, so it makes subtle distinctions in states which NAT doesn't care about.
$ grep ip_conntrack linux/net/ipv4/netfilter/ip_nat_*.c | wc -l 138 $ head -3 linux/Makefile VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 17
Ich denke schon, dass connection tracking und NAT was miteinander zu tun haben...
Adam
On Mon, Dec 31, 2001 at 09:05:03PM +0100, Adam Lackorzynski wrote:
On Mon Dec 31, 2001 at 19:15:17 +0100, Reinhard Foerster wrote:
Das connection tracking hat mit nat erstmal nicht zu tun.
Ich denke schon, dass connection tracking und NAT was miteinander zu tun haben...
jaja, so war das nicht gemeint. Das connection tracking is das "Werkzeug" fürs NAT. Ich wollte nur ausdrücken, daß die vom connection tracking erfassten Verbindungen nicht nur die nat-verbindungen sondern alle sind wenn denn das Modul einmal geladen ist.
Die 2 HowTos (iptables und nat) habe ich mittlerweile durch und vieles getestet. Auf die Frage mit der nat-tabelle habe ich keine Antwort gefunden.
Reinhard
On Mon, Dec 31, 2001 at 07:15:17PM +0100, Reinhard Foerster wrote:
Das connection tracking hat mit nat erstmal nicht zu tun. Die Tabelle muß woanders stehen. Ich hab mal in den News gefragt, vielleicht findet sich da eine Antwort.
Töten der alten Verbindungen geht also nicht. Wer den Thread in den News lesen will findet ihn unter:
http://groups.google.com/groups?hl=en&threadm=bjv13uk2vm5n3ma90aquh1l0lc...
Reinhard
Hallo,
erst einmal Euch allen ein gesundes neues Jahr! Wenn ich das vorhin richtig mitbekommen habe befinden wir uns ja schon voll in 2002 ;-)
Reinhard: Ich habe die nat-Tabelle jetzt richtig gelöscht, aber die muss wohl vorher schon leer gewesen sein - zumindest kann ich in den Ausgaben von iptables -vnL -t nat keine Unterschiede zum "Einschaltzustand" feststellen. Ein Ping vom Client auf eine externe IP ist weiterhin nicht möglich. Im folgenden erst einmal die Ausgaben vom Server:
root@hpnet:/home/matthias# ifconfig -an eth0 Link encap:Ethernet HWaddr 00:80:AD:91:22:4F inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3383 errors:0 dropped:0 overruns:0 frame:0 TX packets:2666 errors:0 dropped:0 overruns:0 carrier:0 collisions:2 txqueuelen:100 Interrupt:11 Base address:0xf8e0
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:83 errors:0 dropped:0 overruns:0 frame:0 TX packets:83 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
ppp0 Link encap:Point-to-Point Protocol inet addr:62.227.184.175 P-t-P:62.155.254.157 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1524 Metric:1 RX packets:32 errors:1 dropped:0 overruns:0 frame:0 TX packets:36 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 +++
root@hpnet:/home/matthias# netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 62.155.254.157 0.0.0.0 255.255.255.255 UH 40 0 0 ppp0 192.168.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo 0.0.0.0 62.155.254.157 0.0.0.0 UG 40 0 0 ppp0
+++
root@hpnet:/home/matthias# iptables -vnL Chain INPUT (policy ACCEPT 694 packets, 37311 bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 466 packets, 33212 bytes) pkts bytes target prot opt in out source destination
+++
root@hpnet:/home/matthias# iptables -vnL -t nat Chain PREROUTING (policy ACCEPT 6 packets, 360 bytes) pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 7 packets, 842 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * ppp0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 7 packets, 842 bytes) pkts bytes target prot opt in out source destination
+++
Ich hoffe dass diese Infos nützlich sind und würde mich riesig freuen, wenn daraus mein Fehler ersichtlich ist.
Viele Grüße,
Matthias
On Tue, Jan 01, 2002 at 01:40:59AM +0100, Matthias Petermann wrote: Tach!
[infos vom server]
Ich hoffe dass diese Infos nützlich sind und würde mich riesig freuen, wenn daraus mein Fehler ersichtlich ist.
Ich bin mal alles durchgegangen und habe nichts falsches gefunden. Du schriebst in einer anderen Mail, daß ein ping vom client auf eine IP nach draußen nichtmal bis zum Server kommt. Dann hat wohl doch der client einen Fehler. Dessen Infos in der ersten Mail waren aber auch ok. Schicke die Infos vom client bitte nochmal in numerischer Form (also alles mit -n).
Reinhard
Hallo,
On Tue, Jan 01, 2002 at 01:21:13PM +0100, Reinhard Foerster wrote:
Ich bin mal alles durchgegangen und habe nichts falsches gefunden. Du schriebst in einer anderen Mail, daß ein ping vom client auf eine IP nach draußen nichtmal bis zum Server kommt. Dann hat wohl doch der client einen Fehler. Dessen Infos in der ersten Mail waren aber auch ok. Schicke die Infos vom client bitte nochmal in numerischer Form (also alles mit -n).
also beim Client sieht das folgendermaßen aus:
bash-2.04$ netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.0.1 255.255.255.0 UG 40 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
+++
bash-2.04$ /sbin/ifconfig -an eth0 Link encap:Ethernet HWaddr 00:80:48:E6:88:6E inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4243 errors:0 dropped:0 overruns:0 frame:0 TX packets:4521 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xe000
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:20 errors:0 dropped:0 overruns:0 frame:0 TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
+++
bash-2.04$ cat /etc/resolv.conf nameserver 217.237.159.1 nameserver 194.25.2.129
+++
bash-2.04$ cat /etc/host.conf order hosts, bind multi on
Die Konfiguration ist seit meiner ersten Mail zum Thema unver- ändert. Würde mich freuen, wenn Du Dir die Ausgaben hier noch einmal ansehen kannst.
Danke,
Matthias
On Tue, Jan 01, 2002 at 04:20:31PM +0100, Matthias Petermann wrote:
Die Konfiguration ist seit meiner ersten Mail zum Thema unver- ändert. Würde mich freuen, wenn Du Dir die Ausgaben hier noch einmal ansehen kannst.
Ist auch alles OK. Hier hört mein Latain für eine Ferndiagnose dann auf :)
Reinhard
Hallo Reinhard,
vielen Dank noch einmal für Deine Mühe. Heute früh hab ich den Masq-Server mal vom PC meines Brüderchens mit Win98 getestet und da lief es auf Anhieb - musste wie gesagt nur den Gateway und die beiden Nameserver eintragen. Der Server sollte also definitiv in Ordnung sein.
Noch einmal die Routen des Linux-Clients:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 255.255.255.0 UG 1 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
Ich hab mir mal die Netzmasken angesehen und wenn ich das richtig verstanden habe, werden in o.g. Konfiguration nur die Adressen des lokalen Netzes über den Gateway geschickt(?) Hinzugefügt habe ich deshalb folgende Route:
bash-2.04# route add default gw 192.168.0.1 netmask 0.0.0.0 metric 1
woraus folgt:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 255.255.255.0 UG 1 0 0 eth0 (*) 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 0.0.0.0 UG 1 0 0 eth0
Damit funktioniert das Routing über den Masq-Server. Nun dachte ich aber, dass sich damit die erste Route (*) erübrigt hat - aber nein: wenn ich diese entferne geht wieder nichts mehr. Hab ich da die Funktion von Netzmasken falsch verstanden? So wie ich mir das angelesen habe sollen die wohl dazu da sein, um bei Erfüllung der Maske durch die IP unter 'Destination' die zugehörigen Pakete über den danebenstehenden Gateway zu leiten.
Viele Grüße,
Matthias
On Tue, Jan 01, 2002 at 07:55:23PM +0100, Reinhard Foerster wrote:
Ist auch alles OK. Hier hört mein Latain für eine Ferndiagnose dann auf :)
On Wed, Jan 02, 2002 at 01:45:35PM +0100, Matthias Petermann wrote:
Haloo Matthias,
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 255.255.255.0 UG 1 0 0 eth0
^^^^^^^^^^^^^^
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
Ich hab mir mal die Netzmasken angesehen und wenn ich das richtig verstanden habe, werden in o.g. Konfiguration nur die Adressen des lokalen Netzes über den Gateway geschickt(?) Hinzugefügt habe ich deshalb folgende Route:
bash-2.04# route add default gw 192.168.0.1 netmask 0.0.0.0 metric 1
Ja, das unterstichene sollte wohl 0.0.0.0 heissen. Genau richtig gesehen.
woraus folgt:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 255.255.255.0 UG 1 0 0 eth0 (*)
Die kannst du dann weglassen. Wo kommt die überhaupt her?
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 0.0.0.0 UG 1 0 0 eth0
Damit funktioniert das Routing über den Masq-Server.
Gratulation ;-)
Nun dachte ich aber, dass sich damit die erste Route (*) erübrigt hat
jo, eben
- aber nein:
wenn ich diese entferne geht wieder nichts mehr.
häh? Kann nicht sein. Route 1 ist nur zuständig für Ziele mit einer IP von 0.0.0.* Diese schickt route 1 an 192.168.0.1. Hättest du route 1 weggelassen käme bei diesen Zielen Route 4 zum Zug, die aber das gleiche Ziel hat. Also ist Route 1 überflüssig.
Hab ich da die Funktion von Netzmasken falsch verstanden?
nein
So wie ich mir das angelesen habe sollen die wohl dazu da sein, um bei Erfüllung der Maske durch die IP unter 'Destination' die zugehörigen Pakete über den danebenstehenden Gateway zu leiten.
naja, unter "Erfüllung der Maske durch die IP" kann ich mir nix vorstellen.
Das ganze funzt etwa so:
Ein Paket hat eine Zieladresse X. Für jede Zeile in der Routingtabelle erfolgt folgendes: { X wird mit der Netzmaske bitweise UND-verknüpft --> ergibt Y Y wird mit Destination verglichen bei Gleichheit --> die Route is ein Kandidat für das Paket X bei Ungleichheit --> route is nicht relevant } Von den Kandidaten fliegen alle die raus, die eine kleinere Netzmaske als andere Kandidaten haben. ("most specific route" bleibt übrig) Diese wird genommen. (Falls mehrere mit gleicher Netzmaske übrig bleiben wird die mit der kleinsten Metric genommen)
3 Beispiele nach deiner Tabelle:
Nr. Destination Gateway Genmask Iface 1. 0.0.0.0 192.168.0.1 255.255.255.0 eth0 (*) 2. 192.168.0.0 0.0.0.0 255.255.255.0 eth0 3. 127.0.0.0 0.0.0.0 255.0.0.0 lo 4. 0.0.0.0 192.168.0.1 0.0.0.0 eth0
------------ Ziel X=192.168.0.20 (X & Netzmaske) passt auf Destination? 1. 192.168.0.0 nein 2. 192.168.0.0 ja 3. 192.0.0.0 nein 4. 0.0.0.0 ja
Wir haben 2 Kandidaten, die Routen 2 und 4. Route 2 hat die größere netmask, wird also genommen. Das Paket geht direkt (ohne weitere gates über eth0 zum Ziel X) Das ist der Verkehr im lokalen Netz.
------------ Ziel X=1.2.3.4 (X & Netzmaske) passt auf Destination? 1. 1.2.3.0 nein 2. 1.2.3.0 nein 3. 1.0.0.0 nein 4. 0.0.0.0 ja
Wir haben nur einen Kandidaten, die Route 4. Also geht das Paket über eth0 ans gateway 192.168.0.1. Dieses Gate kümmert sich dann um den weiteren Weg. Das ist der Fall von Verkehr aus dem lokalen Netz raus ins Internet.
-------- Ziel X=0.0.0.4 (X & Netzmaske) passt auf Destination? 1. 0.0.0.0 ja 2. 0.0.0.0 nein 3. 0.0.0.0 nein 4. 0.0.0.0 ja
Wir haben also 2 kandidaten, die Routen 1 und 4. Da Route 1 die größere Netzmaske hat wird diese genommen. Das ist genau der Fall, wo Route 1 überflüssigerweise genutzt wird. Route 4 hätte das gleiche getan.
Reinhard
Hallo Reinhard,
vielen Dank für deine Beschreibung zum Thema "Netmaske". Ich glaube ich hab es jetzt überhaupt zum ersten Mal richtig ver- standen - und mein Masquerading klappt nun auch ganz prima :-) Nun muss ich den Server nur noch ein bisschen sicher machen...
Viele Grüße,
Matthias
On Sun, Dec 30, 2001 at 03:14:46PM +0100, Matthias Petermann wrote:
Bei "INPUT" und "OUTPUT" kann ich jeweils Traffic registrieren, der wird aber sehr wahrscheinlich nur von Telnet erzeugt, da der Server keinen Monitor+Keyboard hat. Bei "FORWARD" steht da eine Null - also wurde nichts weitergeleitet. Irgendwie vermute ich ein DNS-Problem, da auf dem Client bei z.B. "ping www.gmx.de" immer "unknown host" gemeldet wird. Auf dem Client habe ich in der /etc/resolv.conf die selben Nameserver eingetragen, die auch der Server fuer die Internet- Verbindung benutzt. Aber wie schon geschrieben - auch das direkte Angeben einer IP bringt eine ähnliche Meldung:
erstmal was allgemeines:
Wenn das Netz klemmt bitte immer ERSTMAL NUR IP zum Laufen bekommen, um DNS kümmert man sich DANACH. Deshalb wäre es auch schöner gewesen, wenn du in deiner ersten Mail mit der Problembeschreibung alles nur mit IPs angegeben hättest. (ifconfig -an, netstat -nr, iptables -n) Das kann man viel leichter nachvollziehen und und die Fehlerquelle DNS wird erstmal ausgeschlossen.
bash-2.04# ping 213.165.65.100 PING 213.165.65.100 (213.165.65.100): 56 data bytes ping: sendto: Network is unreachable ping: wrote 213.165.65.100 64 chars, ret=-1
Ähm, du weisst, daß 213.165.65.100 (www.gmx.deW) sowieso NIE auf pings antwortet??? Diese IP ist somit eine eher ungünstige Wahl für den test per ping nach außen :-) Ein network unreachable solltest du trotzdem nicht bekommen sondern ein timeout. Somit ist wohl wirklich eine Route kaputt. Fragt sich nur noch wo.
Also: entweder der Client weiß nicht, wo er seine DNS-Anfragen senden soll oder das Masquerading funktioniert nicht.
.. oder der Client schickt deinen ping nach aussen gar nicht erst an den Server. Bei der in deinem ersten Posting angegebene Routingtabelle des Clients sollte das zwar klappen aber bitte prüfe das nach.
DNS ist bei "ping 213.165.65.100" egal
Was ich vielleicht noch dazu schreiben sollte: Ich habe (vorerst) außer der Masquerading-Regel keine weiteren Regeln angelegt, da ich das Masq. erst einmal so zum Laufen bekommen wollte.
gut so
In der HOWTO steht auch, dass diese minimale Form laufen sollte. Oder müssen notwendigerweise irgendwelche Forwarding-Regeln vorhanden sein, damit auch das Masq. läuft?
nein
Reinhard
lug-dd@mailman.schlittermann.de
-
Adam Lackorzynski -
Andreas Kretschmer -
Matthias Petermann -
Reiner Klaproth -
Reinhard Foerster -
Tobias Koenig -
Torsten Werner