Pakete von Localhost

[maddeb]

Hallo,

ich versuche immer wieder, herauszufinden, warum bestimmte Pakete entstehen. Lange genug im Nebel gestochert, ich frag jetzt.
Es handelt sich um DNS-Abfragen von "::1".
Nun mag es sein, dass mein Verstaendnis von IP zu sehr auf Version 4 beruht. Und aus dieser Welt kenne ich das so, dass Pakete mit der Quelle "127.0.0.0/8" nicht den Quellhost verlassen sollten. Entsprechend werden solche Pakete von den verschiedenen Firewalls zurueckgewiesen und geloggt, warum auch nicht? Selbst, wenn ich das freischalten wuerde, wo soll denn die Anwort hin? An fe80::xxxx:xxxx:xxxx:xxxx und hoffen, dass es keine geroutete Verbindung ist?

Code: Alles auswählen

root@debian:~# cat /etc/resolv.conf 
nameserver fd00::2
domain localhost

Man sieht hier die provisorische Natur des ganzen Setups. Da ich noch keine "echte" Domain habe und localhost wohl als einizge vom DNS-Forwarding ignoriert wird, nutze ich diese. Oder wie waere "localdomain"?

Code: Alles auswählen

root@debian:~# cat /etc/nsswitch.conf 
passwd:         compat
group:          compat
shadow:         compat
hosts:          files dns
networks:       files
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
netgroup:       nis
root@debian:~# cat /etc/hosts
127.0.0.1       localhost
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Diese beiden Dateien sind original.

Gibt es vielleicht sonst noch etwas, z.B. unter /etc, was in Frage kommt, Schuld zu sein? Ich nehme nicht an, dass die Anwendung (hier: StrongSWAN) Schuld ist, weil ich das mit vielen anderen Anwendungen gesehen habe - meistens nur beim/kurz nach dem Booten. In diesem Fall bedeutet dass, dass nach einem

Code: Alles auswählen

service ipsec restart

StrongSWAN funktioniert, aber eben nicht automatisch nach dem Booten ohne manuellen Eingriff.
Deshalb kann ich mir vorstellen, dass das Verhalten in einer fruehen Bootphase normal ist, und die Dienste, die Netzwerk brauchen, eben spaeter gestartet werden sollten. Allerdings half auch das hier, gefolgt von "insserv", nicht:

Code: Alles auswählen

root@debian:/etc# head init.d/ipsec 
#! /bin/sh
### BEGIN INIT INFO
# Provides:          vpn
# Required-Start:    ifupdown $network $local_fs
# Required-Stop:     ifupdown $network $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Strongswan IPsec services
### END INIT INFO
### ifupdown manuell hinzugefuegt

Ach ja, ich sehe zwar darin nicht die Ursache: es geht um VMs, ehemals Xen HVM, seit heute migriert auf KVM (-net nic -net tap), bridged.

Idea, anyone?
Vielen Dank fuer jede Anregung/Spur.

[Natureshadow]

Ähm . . . was denn für Pakete? Kann man die mal sehen?

[maddeb]

Hallo NatureShadow. Klar, kann man.
http://nopaste.debianforum.de/36464

Das ist die Grundinstallation, von der alle anderen VMs abgeleitet werden. Ich hatte aber nur diese heute am laufen im KVM.

Die (einige) VMs haben ein paar Pakete mehr: bind9 hat BIND9 und squid hat Squid3 am laufen, ntp und rsyslog sind ja bereits in der gepasteten Installation enthalten, dass die jeweiligen VMs keine weiteren Pakete installiert haben.

Das gleiche komische Verhalten im DNS zeigte auch damals eine VM mit gogoc, die aber abgeschaltet ist.

Vielen Dank schon mal fuer die Antwort.

[Cae]

was denn für Pakete? Kann man die mal sehen?

jeweiligen VMs keine weiteren Pakete installiert

… da hätte ich jetzt auf Datenpaket getippt, wie das Wort auch von der Bedeutung im Titel verwendet wird. Also etwas mit tcpdump Mitgeschnittenes, nicht unbedingt dpkg --get-selections.

Gruß Cae

[maddeb]

Ups.
Ich habe einen Mitschnitt. Wie postet man hier eine PCAP-Datei?
Naja, ich tu dann mal, was ich kann: in dier Uebersicht sehen die so aus:

Code: Alles auswählen

  1   0.000000          ::1 -> fd00::2      DNS Standard query A debian.localhost
  2   0.028611          ::1 -> fd00::2      DNS Standard query AAAA debian.localhost
  3   3.003201          ::1 -> fd00::2      DNS Standard query A debian
  4   3.034931          ::1 -> fd00::2      DNS Standard query AAAA debian
  5   8.078043          ::1 -> fd00::2      DNS Standard query AAAA vbox.localhost
  6  13.118140          ::1 -> fd00::2      DNS Standard query AAAA vbox

Die Quell-IP sollte fd00::fe sein.

So sieht z.B. das erste aus (direkt aus Wireshark):

Code: Alles auswählen

> Frame 1 (96 bytes on wire, 96 bytes captured)
> Ethernet II, Src: RealtekU_12:34:56 (52:54:00:12:34:56), Dst: Asiarock_01:2b:d7 (00:19:bb:01:2b:d7)
> Internet Protocol Version 6
> User Datagram Protocol, Src Port: 60511 (60511), Dst Port domain (53)
> Domain Name System (query)

0000  00 19 66 01 2b d7 52 54  00 12 34 56 86 dd 60 00   ..f.+.RT ..4V..`.
0010  00 00 00 2a 11 40 00 00  00 00 00 00 00 00 00 00   ...*.@.. ........
0020  00 00 00 00 00 01 fd 00  00 00 00 00 00 00 00 00   ........ ........
0030  00 00 00 00 00 02 ec 5f  00 35 00 2a e6 10 cc 0f   ......._ .5.*....
0040  01 00 00 01 00 00 00 00  00 00 06 64 65 62 69 61   ........ ...debia
0050  6e 09 6c 6f 63 61 6c 68  6f 73 74 00 00 01 00 01   n.localh ost.....

Der ganze Mitschnitt, den ich da habe, geht ueber eine halbe Minute und umfasst fast 400 Pakete. Falls den ernsthaft jemand haben will - ich habe darin jedenfalls nichts komisches entdeckt, abzueglich dieser sechs Pakete hier.

[Natureshadow]

Hi,

das sind ganz normale DNS-Queries. Und wenn fd80::2 auch zu einem Interface deines lokalen Hosts gehört, ist das da völlig legitim.

-nik

[maddeb]

Hi NatureShadow,

Und wenn fd80::2 auch zu einem Interface deines lokalen Hosts gehört, ist das da völlig legitim.

fd00::2 liegt zwar gerade provisorisch im chroot und ist daher wirklich lokal, aber die Anfrage kommt von der MAC 52:54:00:12:34:56, und das ist eine virtuelle Maschine, mit eignenem IP-Stack. Oder so sollte es zumindest sein.

Aber wenn ich so nachdenke, so waere der selbe Fehler unter Xen und KVM zumindest kein Zufall, denn beide benutzen meines Wissens nach Qemu. Mir kommt naemlich gerade in den Sinn, dass ich dieses Verhalten immer wieder bei verschiedenen VMs gesehen habe (und mit dieser Quell-IP ist das immer eine nervige Sucherei), aber nie von der Dom0. Andererseits hatte ich darauf neben den den Xen-Komponenten auch nichts besonderes installliert, so dass wahrscheinlich keine DNS-Abfragen generiert wurden.
Ich installiere jetzt mal StrongSWAN auf der Muttermaschine und passe beim naechsten Boot auf, ob ich das gleiche Verhalten beobachte.

[Natureshadow]

Hi NatureShadow,

Hörst du bitte mal auf, meinen Nickname in CamelCase zu setzen, MadDeb?

Und wenn fd80::2 auch zu einem Interface deines lokalen Hosts gehört, ist das da völlig legitim.

fd00::2 liegt zwar gerade provisorisch im chroot und ist daher wirklich lokal, aber die Anfrage kommt von der MAC 52:54:00:12:34:56, und das ist eine virtuelle Maschine, mit eignenem IP-Stack. Oder so sollte es zumindest sein.

Was ist das für eine Virtualisierung und wie sieht die virtuelle Netzwerkumgebung aus?

Aber wenn ich so nachdenke, so waere der selbe Fehler unter Xen und KVM zumindest kein Zufall, denn beide benutzen meines Wissens nach Qemu.

Häh? Xen und KVM sind Virtualisierungen, Qemu ist ein Frontend für KVM.

[maddeb]

Hallo Natureshadow,
sorry, ich habe wohl bei der ersten Antwort nicht richtig gesehen und dann eine schlechte Gewohnheit entwickelt. Die falsche Schreibweise ist mir nicht aufgefallen. Kommt nicht wieder vor, versprochen.

Häh? Xen und KVM sind Virtualisierungen, Qemu ist ein Frontend für KVM.

Ich mag da etwas falsch verstanden haben, aber ich dachte, der IP-Stack von Xen-HVM- wie auch KVM-Gaesten sei der von Qemu.
HVM-Domains laufen nicht ohne xen-qemu-dm. Vielleicht deswegen

Xen-HVM has device emulation based on the QEMU project to provide I/O virtualization to the virtual machines.

(http://en.wikipedia.org/wiki/Xen)
Aus http://en.wikipedia.org/wiki/Kernel-bas ... al_Machine:

By itself, KVM does not perform any emulation. Instead, a user space program uses the /dev/kvm interface to set up the guest VM's address space, feeds it simulated I/O and maps its video display back onto the host's. QEMU versions 0.10.1 and later make use of this.

Das Paket kvm ist mittlerweile ein Dummy fuer qemu-kvm. Ich hatte angenommen, es installiert auch die Kernelmodule, die man einst aus kvm-source bauen musste, aber vielleicht sind die jetzt auch im Image.

Was ist das für eine Virtualisierung?

Anfangs war alles Xen-HVM. Seit nun aber X11 in der Dom0 (ich hab nur einen Rechner) nicht mehr funktioniert seit ein paar Monaten (Kernelupdate), habe ich alle DomUs in jeweils ein eigenes chroot gesteckt. Der Rechner hat dann alle IPs bekommen, die vorher die einzelnen VMs hatten, um das DNS nicht anzufassen.
Vorgestern habe angefangen die erste VM wieder aus dem chroot zu und mit KVM zu starten.
Die DNS-Pakete waren schon unter Xen zu sehen, auch damals typischerweise beim Boot einer DomU, und von verschiedenen VMs und verschiedenen Anwendungen. Im chroot sind sie nicht logischerweise nicht aufgefallen, weil ja alle Adressen im selben Stack waren.

wie sieht die virtuelle Netzwerkumgebung aus?

Alle VMs haben und hatten genau eine virtuelle Netzwerkkarte, verbunden mit derselben Bridge. Diese hat die IPs der Muttermaschine (fd00::fd und 192.168.1.253). Jeweils ein Subnetz IPv6 und IPv4 (fd00::/64 und 192.168.1.0/24), keine weiteren Segmentierungen und nichts, was an den Paketen herumwerkelt (wie iptables -t mangle/nat).
Keine Defaultroute in IPv6, da ich keinen entsprechenden Zugang habe.

[Natureshadow]

Hi,

ja, KVM stammt aus dem QEMU-Projekt. qemu-kvm ist ein Frontend dafür und enthält in Debian wohl auch einige Kernkomponenten. Aber genau so gut kann auch z.B. VirtualBox als Frontend dienen.

-nik

[maddeb]

Hallo Natureshadow,
sieht so aus, als haettest du auch keine Idee mehr zu meiner eigentlichen Frage, oder?
Da ich das beschriebene Verhalten bisher nur bei bootenden VMs gesehen habe, frage ich mich, ob das auch bei physikalischen Hosts sichtbar ist, wenn sie booten.
Deshalb habe ich mal gerade ein tshark-Kommando in das initscript "networking eingearbeitet und werde morgen sehen.

[maddeb]

So, ich hab das getestet, so gut es ging.
Da das mit dem Autostart von KVM-Instanzen nicht so richtig klappt, nur mit dem BIND9 im changeroot, d.h. fd00::2 ist dann eine lokale Adresse. Die Abfragen, die dann auf dem Loopback-Device zu sehen sind, gehen von dieser Adresse zu dieser Adresse. Das Verhalten ist aber, soweit beobachtbar, anders als das der VMs.
Ich bekomme hoffentlich die naechsten Tage meinen Laptop, da kann ich noch mal versuchen, mit mehr Aussagekraft zu testen.

[maddeb]

So, dass hat gedauert.
Erst hat der Laptop auf sich warten lassen, und dann hatte ich noch dieses Problem hier.
dann stelle ich fest, dass ich keine Moeglichkeit habe, IPv6 zwischen zwei Rechnern auszutauschen, ohne zu kapseln. Hatte einfach keiner ein Crossoverkabel da.
Nun habe ich mein T60 (RIP 2009) exhumiert (d.h. Mainboard ausgetauscht) und das kann Autosensing^^

Ich habe ihm also die IP fd00::2/64 gegeben und den Hai laufen lassen, waehrend der Rechner bootet. Die DNS-Pakete hatten alle einen ordentlichen Absender.
Und ich habe die VM gestartet, waehrend mein Laptop die IP des DNS-Servers hatte. Siehe da, am anderen Ende des Kabels schugen Pakete mit dem Absender "::1" auf.

Fuer mich sieht das danach aus, dass irgendwo der Domainname "localhost", den ich in Ermangelung einer echten Domain benutze, um keine Stoerungen im Netz selber zu verusachen, hartkodiert aufgeloest wird. Ich denke, ich werde bei Gelegenheit mich mal mit dem Code versuchen vertraut zu machen.