Tux

  Menu  
Home

Devel Meeting

Attendees

Gateway

Pictures

All meetings

1st Linux/68k meeting in Oldenburg

Brian hatte 122 identd-Anfragen nicht beantworten koennen :-) (wenn jemand als root genetzwerkt hat, ging es zufaelligerweise, auch brian hat einen root-user). Wenn man aus den identd-Anfragen irgendetwas für Schlüsse ziehen kann, dann wurde sehr viel geirc'ed, dann kommen telnet und finger. Www-Request waren kaum dabei (Obwohl Leute einen Amiga mit Netscape gesehen haben wollen :-))

Leider sind ein paar Kontaktversuche gescheitert. Der genaue Grund ist etwas kompliziert: Auf Brian sind tcp_wrapper installiert, mit den original Slackware-Paranoid-Settings (Compile-time option)). Diese brachen die Verbindung ab, wenn die den anderen Rechner nicht gegenchecken konnten (mittels Nameserver). Der Nameserver laeuft aber auf brian, was an für sich kein Problem ist, nur hab ich ihm sicherheitshalber gesagt, er soll nur Anfragen von localhost und dem lokalen Netz beantworten. Nun hat brian aber noch eine weitere IP-Adresse, nämlich die für die Außenwelt sichtbare. Prozesse können also legalerweise diese IP-Nummer nutzen, und trotzdem brian als Nameserver. Nur verweigert der Nameserver ihnen die Auskunft, weil es weder localhost noch localnet ist. (Mea Culpa, aber darauf muss man erst mal kommen (s. man-page zur bind-funktion)!) Sendmail hat ein ähnliches Problem, wenn es Nachrichten weiterleiten soll. Daher blieben 2 talks und 2 mails am unvollständig konfigurierten Nameserver hängen.

Ein Prozeß (oder was auch immer) hat einen Kernel-Oops fabriziert (im interrupt-code), aber davon steht nur was im Logfile, sonst hat man nix davon gemerkt.

Jetzt aber der interessantere Teil: die Firewall. eth0 war das lokale Netz, eth1 der Rest der Welt.

IP firewall input rules, default policy: deny
 pkts bytes type  prot opt  tosa tosx ifname  ifaddress       source               destination          ports
    0     0 rej   all  ---- 0xFF 0x00 eth0    any             pppnet/30            anywhere             n/a
1941K  103M acc   all  ---- 0xFF 0x00 eth0    any             localnet/24          anywhere             n/a
 4188  602K acc   all  ---- 0xFF 0x00 lo      any             anywhere             anywhere             n/a
3541K 1821M acc   all  ---- 0xFF 0x00 eth1    any             anywhere             bistest1.bis.uni-oldenburg.de n/a
IP firewall forward rules, default policy: deny
 pkts bytes type  prot opt  tosa tosx ifname  ifaddress       source               destination          ports
    0     0 acc   all  ---- 0xFF 0x00 any     any             localnet/24          localnet/24          n/a
1831K   77M acc/m all  ---- 0xFF 0x00 any     any             localnet/24          anywhere             n/a
IP firewall output rules, default policy: deny
 pkts bytes type  prot opt  tosa tosx ifname  ifaddress       source               destination          ports
    3   252 rej   all  ---- 0xFF 0x00 eth0    any             anywhere             pppnet/30            n/a
3587K 1860M acc   all  ---- 0xFF 0x00 eth0    any             anywhere             localnet/24          n/a
 4200  604K acc   all  ---- 0xFF 0x00 lo      any             anywhere             anywhere             n/a
1907K   83M acc   all  ---- 0xFF 0x00 eth1    any             bistest1.bis.uni-oldenburg.de anywhere             n/a

Das hier ist die Kurzfassung unseres Traffics:

IP accounting rules
 pkts bytes dir prot opt  ifname  ifaddress       source               destination          ports
2056K  157M i/o all  ---- any     any             localnet/24          anywhere             n/a
3695K 1885M i/o all  ---- any     any             anywhere             localnet/24          n/a

Das heißt, daß es insgesamt etwas über 2GB waren und das in-out-Verhältnis etwa 1/11 ist. Hoffentlich ist das keinem aufgefallen, das es etwas viel war für eine Bibliothek am Wochenende.

Noch ein Tip: Mit ppp tippt man pppd /dev/cua0 : defaultroute auf client-seite pppd /dev/cua0 : proxyarp auf server-seite (server = Rechner mit Netzwerkkarte, hier gilt ppp-ip = ethernet-ip) und schon hat hat man die verbinung laufen. Die host-route macht pppd sowieso, genauso wie das ifconfig, etc. Im vergleich zu slipspart das mind. 3 hochkomplizierte befehle (alles pot. Fehlerquellen), und man kann bei nicht 8-Bit-dichten Verbindungen jedes Zeichen in jeder Richtung einzeln escapen. Ausserdem hat es auf Anhieb geklappt und spart ip-nummern.

Jörg Dorchain

© Joey, last modified: September 7, 2001, page source · Oldenburger Linux Developers Meeting