Die deutsche Wirtschaft besteht hauptsächlich aus kleinen, spezialisieren Unternehmen. Die meisten von ihnen haben nichts mit IT am Hut, brauchen es aber trotzdem. Also holen sie sich einen Bekannten als Dienstleister bis irgendwann mal aufgeräumt werden muss.

Der Auftrag

Ein typisches 10-Personen-Unternehmen wendet sich an uns, weil ein Bekannter uns empfahl.

Die Firma gibt es schon lange, hat in diese Gegend hier expandiert und nun diesen Teil abgespalten. Dieser Teil braucht also neue, eigenständige IT. Der Auftrag besteht darin, herauszubekommen, welche Dienste die Ex-Abteilung überhaupt benötigt, wo die bisher betrieben wurden und wie man die separiert. Natürlich muss die Umstellung im laufenden Betrieb stattfinden.

So weit, so gut.

Dass zu den meisten Dienstleistungen – weil bisher intern – keine Verträge existieren, ist nachvollziehbar. Dass die Mitarbeiter nur ihre Arbeit machen, so wie man es ihnen gesagt hat, ist nachvollziehbar. Dass bei der Hauptfirma keiner weiß, welche Dienste existieren und welche Verträge bestehen, ist schwierig aber eben auch nicht zu ändern. Dass die bisherigen Dienstleister nicht zwingend Lust haben zu helfen, ist nachvollziehbar.

Kurz und gut, der Auftrag besteht mehr aus Unternehmensberatung als aus Technik. Es gelingt, über mehrere Monate hinweg, Daten zu verlagern, Dienste wie Steuerbüro, Bank, Dokumentenverwaltung, E-Mails, Webauftritt neu aufzusetzen.

Branchensoftware

Was sich als wirklich schwierig gestaltet, ist die eingesetzte Branchenlösung.

Selbstverständlich gibt es online so gut wie keine Dokumentation, denn die Lösung wurde von einem anderen KMU entwickelt und ist nur regional von Bedeutung. Sie ist aber groß genug, um die Abwicklung ausschließlich über Partner (Systemhäuser) zu realisieren.

Selbstverständlich ist jede Installation eine individuell angepasste Vor-Ort-Installation, für die der Hersteller weder Auskunft gibt, noch davon Kenntnis hat. Die klassische Antwort ist da in der Regel: Diese Version ist völlig veraltet.

Es stellt sich heraus, dass die Mitarbeiter über ein VPN auf einem Terminalserver an einem anderen Firmenstandort arbeiten. Leider kann niemand etwas zu dem Server und der dortigen Software sagen. Der betreffende Mitarbeitet ist schon länger nicht mehr angestellt.

Bei einem Vor-Ort-Termin bekommen wir heraus, dass die Software offenbar nur ein Frontend ist, die ihrerseits ein Backend anspricht. Wo dieses Backend steht, weiß keiner.

Die Backend-IP führt zu einem Systemhaus in der Nachbarstadt. Dort weiß man zunächst nichts von dem Kunden oder gar einem Serverbetrieb. Mehr aus Neugier folgt man unseren Angaben und meldet zurück: Endlich wissen wir, was diese Maschine da soll. Wir konnten die bisher nicht zuordnen. Übernehmen Sie die?

Selbstverständlich gibt es weder Vertrag zwischen Firma und Systemhaus, noch irgendwelche Zahlungen, wobei man bei letztem allgemein unsicher ist.

Technik

Was dann bei uns ankam, waren drei Geräte.

Man sagte uns, ein Server habe viele Festplatten und sei echt schwer. Es steht APC drauf. Sie haben also die USV mit ausgebaut und versendet.

Ein Server ist ein Tower, der andere im 19" Einbaurahmen. Mal sehen, was da drauf ist.

Ja, die Erwartungen an das heutige Internet haben sich gewandelt. Es ist nicht mehr die vorgeblich heile Welt, in der man vertrauensvoll mit anderen kommunizieren konnte. Jeder Dienstleister, sei es die besuchte Webseite oder der eigne Provider, wird argwöhnisch unter die Lupe genommen. Über all diesem steht die Furcht vor der Politik, dem Staat und den Geheimdiensten.

Lauscher

Es ist nur vernünftig, nicht zu gutgläubig im Netz unterwegs zu sein. Man kann seine E-Mails verschlüsseln (und macht es doch nicht), man kann darauf achten, Webseiten nur über verschlüsseltes HTTPS zu besuchen, man kann SSH und viele andere verschlüsselte Protokolle nutzen. Alle diese Methoden schützen vor dem Ausspionieren auf dem Transportweg.

Aber sie tun es nicht vollständig. Immer noch kann man erkennen, wer mit wem wie viel Daten austauscht. Um das zu verschleiern, muss man auf TOR-Netzwerke setzen. Eine andere Alternative ist es, sämtliche Nutzungsarten auf wenige große Anbieter zu verteilen. Man geht nicht nur in der Masse unter, sondern läßt den Mitlauscher auch im unklaren über seine detaillierten Aktivitäten.

Wer bin ich?

Trotzdem bleibt ein weiteres Problem: Die Namensauflösung. Wir sind es gewohnt, bei E-Mail-Adressen, URL-Zeilen, Spiele-Servern, ja bei jeder Interaktion mehr oder weniger sprechende Namen zu benutzen. Der Dienst, der die Namen in IP-Adressen der zugehörigen Server umwandelt ist das DNS, das Domain-Name-System.

DNS ist clever konstruiert, es funktioniert wie eine verteilte Datenbank. Die innere Struktur der Namen entspricht Hierarchieebenen, die in unterschiedlicher Verantwortung stehen und von vielen verschiedenen Parteien betrieben wird. Die Delegation reicht bis in die Firma oder den Hobbykeller. Von dort aus wird die ganze Welt mit Auskünften versorgt, falls mal jemand wirklich was mit mir zu tun haben will. Das System stellt die Auskunftsdaten in den Hoheitsbereich des jeweiligen (Web-, Mail-)Server-Betreibers. Die Entscheidung, wer welche Auskunft bekommt, liegt damit praktisch beim Endnutzer. So kann eine Firma beispielsweise intern mehr und andere Dienste betreiben als nach außen sichtbar sein sollen.

Eine weitere clevere Idee ist, die Namensauflösung in spezielle Software, die Resolver, durchzuführen. Alles, was diese Software benötigt, ist ein Internetzugang und eine kleine Anzahl fester Root-Server-Adressen, die zu wirklich jeder Frage eine Antwort kennen (auch wenn diese nur heißt, man möge bitte da drüben nachfragen). Diese Resolver merken sich alle Ergebnisse, die sie im Laufe der Zeit zu Gesicht bekommen und halte sie eine bestimmte (einstellbare) Zeit vor. So können sie viele Anfragen direkt beantworten und belästigen nicht den Rest der Welt. Caching sorgt so dafür, dass die Last der DNS-Quell-Server nicht zu groß wird. Da diese Resolver so wenig Anforderungen stellen, kann und soll praktisch jeder und jedes Gerät einen solchen Resolver betreiben.

Früher waren jedoch nicht alle Geräte so leistungsstark, einen vollen Resolver selbst zu betreiben. Also hat die Firma oder der Provider einen großen, leistungsfähigen zentralen Resolver hingestellt den alle Clients benutzen. Der Caching-Effekt wird durch diese regionale Zentralisierung größer, es werden deutlich weniger Anfragen an die DNS-Quell-Server geschickt.

Fäschungen und Zensur

Das Problem mit dem System ist, dass alle Anfragen unverschlüsselt und unauthentisiert sind. Jeder auf dem Weg kann mitlesen und die Antworten beliebig verändern. Da veränderte Antworten gefährlich sind (Umlenkung der Bankseite zu Phishern), wurde DNSSEC erfunden. Es unterschreibt die DNS-Antworten und verhindert somit eine Manipulation. Wer als Betreiber einer eigenen Zone diese nicht unterschreibt, handelt fahrlässig. Es ist wie der Betrieb eines HTTP-Server ohne HTTPS: Man bringt seine Nutzer und Kunden in Gefahr.

Auch die letzte Meile, also die Verbindung zum zentralen Resolver kann man mit DNSSEC gegen Manipulationen schützen. Alternativ kann man hier auch auf die gehypten Verfahren DNS-over-TLS (DOT) oder DNS-over-HTTPS (DoH) setzen, die zusätzlich die letzte Meile verschlüsseln. Besser ist es aber gleich einen eigenen DNSSEC validierenden Resolver auf dem Endgerät zu betreiben, denn das schützt auch gegen Manipulationen am vorgegeben Resolver selbst. Einige Provider lenken Tippfehler auf eigene Seiten um (NXDOMAIN-Rewriting), das muss man sich ja nicht antun.

Bleibt das Problem, das DNS Anfragen i.d.R. immer den vollen Namen anfragen als z.B. www.heise.de, auch wenn sie sich an einen Root-Server wenden. Die Idee dabei ist, die Antwortzeiten zu verkürzen, wenn der angefragte Server ohnehin schon mehr Details kennt, die er gleich mit schicken kann. Solche zusätzlichen Antworten wurden für Angriffe ausgenutzt, indem der DNS-Server von firma.de bei der Frage nach www.firma.de auch immer gleich noch eine (falsche) Antwort für www.heise.de mitschickte und die Resolver diese treudoof lernten. Mit DNSSEC wird es wieder möglich, diese zusätzlichen Antworten auszuliefern, weil der Resolver sie anhand der Signaturen als valide erkennen kann. Hat man das nicht, muss man mit den Antworten sorgsam umgehen.

Privatsphäre

Das Privacy-Problem ist nun noch anzugehen: Alle Root-Server bekommen die vollen Anfragen zu sehen. Aber auch hier gibt es seit Anbeginn eine Empfehlung: DNS kann Zoneninhalte komplett transferieren. Mit AXFR (Vollabzug) oder IXFR (Änderungen) kann ein Resolver präventiv die komplette Zone ein lernen und braucht nie wieder die Quell-Server mit konkreten Fragen zu belästigen. Die Root-Zone unterstützt das Modell, es ist für jeden Nutzer, der Wert auf Privatsphäre legt, zu empfehlen.

Die meisten Top-Level-Domains unterstützen den Zonentransfer nicht, meist aus markenrechtlichen Überlegungen. Hier würden also zumindest ein Teil der Anfragen aufschlagen. Es gibt seit eingen Jahren jedoch auch Resolver, die gerade bei den TLDs nur nach der delegierten Zone fragen und so die Privatsphäre der Anwender schützen.

Auch für private oder Firmen-Zonen ist ein offenes AXFR meist sinnvoll. Nicht nur, dass man wichtige Server so wesentlich stabiler betreibt, man gestattet so auch seinen Nutzern eine höhere Privatsphäre. Selbstverständlich darf man ins DNS keine ernsthaften Geheimnisse rein schreiben, aber das macht man ja sowieso nicht. Mit beliebig vielen Versuchen kann man die Namen immer automatisiert herausbekommen.

Fazit

Zusammengefasst kann man sagen: DNS ist gereift, es kann mit den Bedrohungen der Überwachung und Zensur umgehen. Alles was man tun muss, ist einen eigenen, validieren Resolver zu betreiben, wenn möglich mit einer Kopie der Root-Zone. Bis auf DNSSEC (gegen Zensur) sind das alles Empfehlungen aus den Frühzeiten des DNS.

Wenn ein Protokoll alt wird, stirbt mangels Nutzung einfach aus. Protokolle wie DNS überleben jedoch, indem sie sich an geänderte Anforderungen anpassen oder flexibel genug eingesetzt werden können.

Mein persönlicher Vorwurf an die Protagonisten von DoH ist folgender: Wer ein verteiltes System zugunsten einer Handvoll großer Anbieter aufgibt, dabei aktive Nutzungsfälle wie Split-DNS sabotiert und auf lokale Validierung verzichtet, der bekommt zentrale Überwachungs- und Zensursysteme. Es ist von einem technischen Redakteur unverantwortlich, seine Leser derartig in die Irre zu führen und sie damit in Gefahr zu bringen.

Das Internet basiert auf zwei grundsätzlichen Prinzipien: Dezentraliät und Interoperabilität. Internet ist das genaue Gegenteil von großen, zentralen Plattformen. Es ist die große, weite Landschaft, nicht der eingezäunte Garten.

Wenn ein ISP über seine Außenanbindungen Traffic schaufelt, dann ist es oft Glückssache, welches Leitung wieviel Daten abbekommt. Natürlich wird man gezielt versuchen einige Teilnetze nur auf einigen bestimmten Upstreams zu announcieren, damit genau dort der Traffic auch rein kommt. Aber das Finetuning ist sehr schwer. Man müßte ziemlich genau wissen, welcher Datenstrom zu welcher Zeit auf welchem Weg durchläuft, um die Änderung planen zu können.

Details bitte

Kürzlich hatte ich über Netflow geschrieben. Dort wurden die Datenströme nach Quell- und Ziel-AS summiert. jetzt will ich es detaillierter haben.

Weiterhin benötigt werden nun:

  • Der Router, der die Daten einsammelt.
  • Das Peer-ASN mit dem der Router direkt redet.
  • Der Netzblock, der im globalen Routing auftauchen wird.
  • Und der Schönheit wegen, der lokale Dienst, der den Traffic abbekommt oder initiiert.

Um nicht sämtliche IP Adressen als relevant ansehen zu müssen, definiere ich mir einen neuen Flow pro Richtung:

flow record in
 match routing source as 4-octet
 match routing source as peer 4-octet
 match routing destination as 4-octet
 match ipv4 destination address
 match ipv6 destination address
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long
flow record out
 match routing source as 4-octet
 match routing destination as 4-octet
 match routing destination as peer 4-octet
 match ipv4 source address
 match ipv6 source address
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long

Zusätzlich zu den Quell- und Ziel-ASNs nehme ich nun auch noch das Peer-ASN und die Quell- oder Ziel-IP dazu.

So beschränke ich mich auf die IP-Adressen im lokalen Netz (oder halt Transit) und aggregiere auf dem Router schon über die unbekannten externen IPs. Es wäre denkbar, auch IP-Prefixe statt der Adresse zu nehmen, aber ich habe Routing-Objekte, die kleiner sind als einige Prefixe. Also bleibt es bei den Adressen.

IPv4 und IPv6 sind zusammengefaßt, eine von beiden Werten wird schon relevant sein.

Als erste Überraschung präsentiert mir die Ausgabe Peer-ASN an Routern, die gar keine direkte Verbindung zu diesem AS haben!

Es stellt sich heraus, daß das Peer-AS ein abgeleiteter Wert ist, der durch ein Blick in die Routing-Tabelle ermittelt wird. Es zeigt also immer auf das Peer-AS, das der Router genommen hätte, wenn er das Paket jetzt in diese Richtung routen müßte.

Logischerweise ist also das Source-Peer-ASN i.d.R. falsch. Aber auch das Destination-Peer-ASN kann falsch sein, wenn es mehrere gleichberechtigte Wege gibt. Es ist durchaus möglich, das Pakete zum Peer 1 zu schicken und Peer 2 im Netflow zu hinterlegen.

Also stelle ich erstmal auf incoming und outgoing Interface um. Unglücklicherweise kann der Netflow-Collector überhaupt nicht damit umgehen, nur ein Interface zu bekommen. In der Annahme es gäbe beide Interfaces im Flow werden einfach die nächsten zwei Byte nach dem ersten Interface als das fehlende Interface angesehen. Alle anderen Felder werden danach mit einem Offset von zwei völlig fehlerhaft geparst. Also bekommt der Collector seinen Willen und das fehlende Interface (aber nur collected).

flow record in
 match routing source as 4-octet
 match routing destination as 4-octet
 match interface input
 match ipv4 destination address
 match ipv6 destination address
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long
 collect interface output
flow record out
 match routing source as 4-octet
 match routing destination as 4-octet
 match ipv4 source address
 match ipv6 source address
 match interface output
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long
 collect interface input

Achja, die Router-IP. Der nfcapd hat mehrere Module, die man getrennt aktivieren muß. Das Modul 13 schreibt die IP-Adresse des Netflow-Sensors (des Routers) mit.

Damit sind die Werte erst einmal erfaßt.

Mach mal bunt

Da mich aktuell nur IPv4 interessiert genügt es für die Auswertung sich darauf zu konzentrieren:

nfdump -r ... -q -N -A srcip4/26,srcas,inif,router,outif,dstas,dstip4/26 -O bps

Dieses Kommando aggregiert auf Basis von /26er Netzen, für die ich händisch im Auswertescript hinterlegt habe, welches Routing-Object und welcher Zweck gemeint sind.

Das Script schreibt die aggregierten Daten alle fünf Minuten in ein Logfile. Es ersetzt dabei die Interfaces pro Router mit den Peer-AS-Werten anhand einer manuellen Zuordnungstabelle.

Das Script versucht des weiteren, Flows von Transit-Traffic korrekt zuzuordnen. Wenn Quell- und Ziel-ASN ungleich Null sind, habe ich Transit.

Sind auf einem Router Quell- und Ziel-Interface einem Peer zugeordnet ist es einfach, wenn nicht muß man den eingehenden Flow einem Ausgehenden zuordnen, der die gleichen Quell- und Ziel-ASNs aufweist. Dabei kann es passieren, daß der Traffic aufspaltet. In dem Fall entnehme ich das Minimum an übereinstimmenden Traffic und ordne den Rest solange weiter zu, bis der Resttraffic unter der Nachweisgrenze verschwindet.

Im Ergebnis entstehen Einträge der Form:

DHCP 91.137.60.0/22 rudo5 8220 other 94
2906 8220 rudo5 178.19.237.0/24 NAT 86
other 196714 rudo7 178.19.228.0/22 NAT 85
2906 8220 rudo8 rudo6 196714 196714 83

Der Flow ist von links nach rechts zu lesen und die letzte Zahl ist der Traffic in Mbps.

Aus diesen Angaben generiert sich mit Javascript ein SVG.

SVG deswegen, weil es interaktiv ist:

  • Man kann die Daten in fünf-Minuten-Schritten auswählen.
  • Fährt man mit der Maus über eine Kurve, so wird diese hervorgehoben und der Eintrag erscheint als Tooltip.
  • Fährt man mit der Maus über ein Rechteck (Router, Peer, Netz, ...) werden alle durchlaufenden Kurven hervorgehoben und man bekommt die Summenbandbreite als Tooltip.
2018-09-24-163642_1280x1024_scrot

Grün ist eingehender Traffic, blau ausgehender und rot ist Transit. Die Dicke der Linie und die Größe der Rechtecke geht linear mit dem Traffic. Router und Peers haben die Größe der maximalen Kapazität. so sieht man den Auslastungsstand.

Mit dieser Darstellung kann ich nachträglich mir anschauen, was zu bestimmten Stoßzeiten im Netz los war. Ich sehe, welche Routing-Objekte evtl. besser über einen anderen Upstream announciert werden könnten. Auf diese Weise kann ich sehr fein abstimmen, wieviel Traffic auf welcher Leitung herein kommt und muß erst wesentlich später neue Bandbreite zukaufen.

Das Aggregationsschema führt allerdings auch in die Irre. Es ist nicht unterscheidbar, ob es 5000 Flows mit 1 Mbps gab oder 10 Flows mit 500 Mbps: Angezeigt werden 5 Gbps. Das fiel auch erst spät auf, als ein Scan über alle IP Adressen trotz nur wenig Mbps sich zu einem gewaltigen Strom aufplusterte. Aber damit muß man aktuell leben.

Was bei einem ISP so rein und raus geht, ist für die Planung wichtig und für Traffic-Engineering essentiell. Um diese Informationen abzugreifen, hat der Netzwerk-Gott Netflow erfunden. Normalerweise ist Netflow zu detailliert, um es auf höheren Bandbreiten einsetzen zu können, also muß man schon am Router aggregieren.

Beschränkung aufs Relevante

Von Interesse ist, mit welchen Autonomen Systemen der ISP Daten austauscht. Genau dafür gibt es ein vordefiniertes Profil:

#show flow record netflow ipv4 as      
flow record netflow ipv4 as:
  Description:        AS aggregation schemes
  No. of users:       0
  Total field space:  29 bytes
  Fields:
    match routing source as
    match routing destination as
    match interface input
    match interface output
    match flow direction
    collect counter bytes
    collect counter packets
    collect timestamp sys-uptime first
    collect timestamp sys-uptime last

Der entsprechende Eintrag ist gar nicht von der IP Version abhängig und paßt genauso auch auf IPv6. Er definiert einen Flow primär anhand des Quell- und Ziel-ASN. Für alle Pakete, die in allen match-Feldern übereinstimmen, werden die collect-Felder gesammelt. Ob summiert, das Minimum oder das Maximum genommen wird, ist vom jeweiligen Feld abhängig.

Den aufgesammelten Datenwust kann man sich lokal anschauen oder exportieren:

flow exporter server8
 destination 192.0.2.8
 source Loopback0
 transport udp 9995
flow monitor asn
 exporter server8
 record netflow ipv4 as
interface TenGigabitEthernet0/1/0
 ip flow monitor asn input
 ip flow monitor asn output
 ipv6 flow monitor as input
 ipv6 flow monitor asn output

Soweit so einfach.

Auf dem betreffenden Server läuft dann ein Netflow-Collector, der die Daten einsammelt und alle fünf Minuten in eine extra Datei auf der Platte ablegt. Auf dieser Datei führe ich nun meine Aggregation aus.

~# nfdump -r /var/spool/netflow/2018/09/27/12/nfcapd.201809271200 -A srcas -O bps | head
Date first seen          Duration  Src AS   Packets    Bytes      bps    Bpp Flows
2018-09-27 11:58:23.111   400.103   15169    38.9 M   47.7 G  953.1 M   1225 25304
2018-09-27 11:58:22.973   401.026       0   157.9 M   45.9 G  915.4 M    290 714869
2018-09-27 11:58:24.009   399.987    2906    23.3 M   34.4 G  688.4 M   1474  1223
2018-09-27 11:58:23.215   400.643   16509    26.0 M   33.7 G  673.7 M   1297 34785
2018-09-27 11:58:23.167   399.702   16097    18.3 M   27.0 G  541.3 M   1477  2560
2018-09-27 11:58:23.143   399.853    3356    16.9 M   25.2 G  503.6 M   1486  3869
2018-09-27 11:58:23.411   396.579    6185    15.3 M   22.7 G  458.5 M   1488  3624
2018-09-27 11:58:29.698   393.297   22822    10.8 M   16.0 G  324.6 M   1482   734
2018-09-27 11:58:23.095   400.807   32934    11.7 M   14.6 G  292.4 M   1251 11138

Sehr schön. Das AS0 ist Traffic, der von lokal kommt (ausgehend also). Dann plotte ich das mal auf:

2018-09-13-151512_447x228_scrot

WTF? Das ist definitiv nicht korrekt.

Fehlersuche

Bei der Auswertung sind ja viele einzelne Flows nochmal nachaggregiert worden. Wenn man die sich einzeln anschaut, dann gibt es keinen einzigen Flow, der mehr als 4,3 GByte an Daten enthält. Und von diesen gibt es eine ganze Menge. Alle mit der identischen Datenmenge.

Was ist passiert?

#show flow exporter templates
  Client: Flow Monitor asn
  Exporter Format: NetFlow Version 9
  Template ID    : 0
  Source ID      : 0
  Record Size    : 29
  Template layout
  _____________________________________________________________________
  |                 Field                   |  Type | Offset |  Size  |
  ---------------------------------------------------------------------
  | timestamp sys-uptime first              |    22 |     0  |     4  |
  | timestamp sys-uptime last               |    21 |     4  |     4  |
  | counter bytes                           |     1 |     8  |     4  |
  | counter packets                         |     2 |    12  |     4  |
  | interface input snmp                    |    10 |    16  |     4  |
  | interface output snmp                   |    14 |    20  |     4  |
  | flow direction                          |    61 |    24  |     1  |
  | routing destination as                  |    17 |    25  |     2  |
  | routing source as                       |    16 |    27  |     2  |
  ---------------------------------------------------------------------

Der Byte-Zähler hat eine Größe von 4 Byte, also 32bit, was genau bis 4294967295 enthalten kann. Anders gesagt: Mehr als 4,3 GByte kann man nicht pro Flow exportieren. Und diese Grenze wird immer wieder gerissen.

Normalerweise ist es kein Problem, einen Flow auf 4GB zu beschränken, da die typische Flow-Definition auch IPs und Portnummern enthält. Mit ausgelasteten 100Mbps braucht man für diese Datenmenge fast sechs Minuten, also mehr als das Meßintervall.

Hier jedoch wird schon auf Routerseite stark voraggregiert, die IP Adressen oder gar die Portnummern spielen keinerlei Rolle mehr. Deswegen werden deutlich weniger Flows erzeugt und exportiert. Andererseits werden die Zähler nun aber deutlich größer.

Ebenfalls auffällig ist, daß auch für die AS-Nummern nur 2 Byte zur Verfügung stehen. Und tatsächlich sind im Export alle 4-Byte ASNs durch 23456 ersetzt, so wie es RFC 4893 vorschreibt. Für die Auswertung ist das natürlich witzlos.

Also definiere ich mir einen maßgeschneiderten Record:

flow record asn
 match routing source as 4-octet
 match routing destination as 4-octet
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long

Und siehe an, das schaut viel besser aus. Wie im obigen Bild zu sehen ist, habe ich die Änderung am ersten Router gegen 17 Uhr vorgenommen. Die Spitzen sind danach deutlich angestiegen.

Aber warum überhaupt die seltsamen Spitzen? Alle halbe Stunde steigt der Traffic stark an, um dann wieder abzufallen? Sehr unwahrscheinlich.

Es sieht so aus, als ob die Flow-Records schlicht nicht gleichmäßig ankommen, sondern schubweise.

#show flow monitor asn
Flow Monitor asn:
  Description:       User defined
  Flow Record:       asn
  Flow Exporter:     server8
  Cache:
    Type:                 normal (Platform cache)
    Status:               allocated
    Size:                 200000 entries
    Inactive Timeout:     15 secs
    Active Timeout:       1800 secs
    Trans end aging:   off

Der Timeout für aktive Flows, also die, auf denen weiter Daten rein kommen, ist 1800 Sekunden, 30 Minuten, eine halbe Stunde!

Selbstverständlich sind bei der aggressiven Aggregation alle Flows dauerhaft aktiv. Sie werden also still aufsummiert und die Zwischensummen alle halbe Stunde exportiert. Im Ergebnis sieht man die Spitzen, da fast alle Flows zu der Zeit beginnen, als Netflow auf dem Interface aktiviert wurde.

Da alle fünf Minuten ein Snapshot beim Collector weggeschrieben wird, sollte man etwas häufiger Zwischensummen exportieren.

flow monitor asn
 exporter server8
 cache timeout active 100
 cache timeout update 150
 record asn

Und schon flutscht es.

2018-09-24-164028_497x248_scrot

Ein Kunde beschwert sich über eine kaputte Firewall. Die würde abstürzen und müsse immer wieder rebootet werden. Als Verkäufer sollen wir das Gerät tauschen. Aus dieser eigentlich trivialen Aufgabe wurde eine beinahe unendliche Geschichte.

Fehlerbild

Seit einigen Monaten kann der Kunde beinahe jeden Morgen nicht arbeiten. Manchmal ist es Dienstag und Donnerstag. Man manchmal Montag, Mittwoch und Freitag. Manchmal auch ganz anders. Reboot der Firewall und es geht alles wieder. Logischerweise vermutet er einen Defekt an diesem Gerät und möchte einen Hardware-Tausch.

Andererseits macht der Hersteller Streß, wenn funktionierende Technik (unnötig) getauscht werden soll. Ich brauche also zumindest den Ansatz einer Fehlerursache.

Zunächst stellt sich heraus, daß die Reboots zu regelmäßig sind, um auf einen Hardwareschaden hinzudeuten. Jeden Tag um die gleiche Uhrzeit rebootet das Gerät. Auf Rückfrage sagt der Kunde, daß er die Faxen dicke hatte und per Zeitschaltuhr den Reset erzwingt.

Das Logging liegt nur auf dem Gerät selbst vor, so daß keine Aussagen über die Zeit vor dem Reboot getätigt werden können. Der Kunde aktiviert wieder seinen Syslog-Server, der das anfangs noch entgegen genommen hatte. Mangels Nutzeffekt hat man den Server vor einiger Zeit schon abgeschaltet.

Mit dem Syslog ergeben sich nun neue Einsichten:

  • Irgendwann zwischen drei und fünf Uhr fällt das Interface zum Internet-Modem aus und kommt kurz danach wieder.
  • Es taucht ein Gerät im Syslog auf, daß auch im diese Zeit herum in den Stromsparmodus geht und daraus wieder erwacht. Das Gerät hat leistungsstarke Motoren.
  • Die Firewall macht DHCP in Richtung Internet und erneuert alle 5h ihre 10h-Lease.
  • Die Reboots werden inzwischen manuell über die GUI der Firewall zwischen fünf und sechs Uhr ausgelöst.
  • Vor den Reboots meldet die Firewall, daß sie auf Pakete ins Internet keine Antwort bekommt.

Ursachenforschung

Der auffälligste Punkt ist, daß die Firewall nicht völlig kaputt sein kann, wenn man sie über die GUI rebootet.

Die nächste Korrelation ist das Gerät mit den Motoren. Wenn es an oder aus geht, könnte es Störungen im Stromnetz verursachen und so einen Fehler triggern. Auch könnten hochfrequente Störungen den Internetzugang unterbrechen. Schließlich gibt es da ja einen Interface Reset. Der Kunde sagt, das Gerät sei erst vor einigen Monaten angeschafft worden. Das korreliert auffällig mit dem Zeitpunkt ab dem Störungen auftraten. Der Kunde schließt diese Ursache aber kategorisch aus.

Also bleibt die Frage nach dem Internetzugang. Ein Anruf beim Provider (einem kleineren) bringt neue Erkenntnisse:

  • Vor einigen Monaten ist aufgefallen, daß die Anschlußtechnik beim Kunden nicht regelmäßig rebootet wird.
  • Man hat die Geräte in Richtung des Kunden in die Liste der automatischen Reboot aufgenommen.
  • Die Reboots werden sequentiell ausgeführt, eine Sortierung wird nicht erzwungen. Man möchte es zufällig halten.

Wahrscheinlich passiert folgendes:

  • Der Provider rebootet Teile seines Netzes.
  • Die Zuleitungstechnik vergißt dabei die ausgeteilte DHCP Lease, leitet also keine Daten mehr weiter.
  • Im Schnitt erneuert ein Endgerät 2,5h nach dem Reboot die Lease und es geht wieder.
  • Der Kunde beginnt regelmäßig um 5 Uhr mit Arbeiten.
  • Er bemerkt die fehlende Konnektivität und rebootet die Firewall.
  • Die Firewall holt sich direkt beim Booten per DHCP eine neue Adresse und alles geht wieder.

Man kann jetzt ausrechnen, wie hoch die Wahrscheinlichkeit ist, daß der Kunde um 5 Uhr noch keine Konnektivität hat.

Man kann auch die Firewall einmal so rebooten, daß die Lease immer zwischen 4 und 5 Uhr erneuert wird. Dank der 10h Lease ist dieser Rhythmus ja ziemlich stabil, er verschiebt sich täglich um 4h nach vorn. Das erklärt, warum der Kunde den Effekt nicht jeden Tag hat, sondern im Abstand von zwei bis drei Tagen beobachtet.

Man kann aber auch den Provider bitten, nicht zu rebooten.

Fazit

Internetprovider benutzen die Zeit zwischen Mitternacht und sechs Uhr morgens für beliebige, unangekündigte Arbeiten. In dieser Zeit gibt es keinerlei Funktionsgarantie für alles, was irgendwas mit Telekommunikation zu tun hat. Die gesamte IT-Branche benutzt die Nacht für Wartung, Umbauten und Updates.

Die Fachbegriffe der Informatik kennen es so:

337: Uptime Verfügbar an Werktagen zwischen 9:00 und 12:00, sowie 14:00 bis 17:00. (Microsoft SQL Server 2000 Administrator's Companion)

Denk ich an #Neuland in der Nacht, bin ich um den Schlaf gebracht.

nach Heinrich Heine

Die finale Umsetzung der DSGVO ist nun bald 100 Tage alt. Da läuft mir ein Interview mit dem Landesdatenschutzbeauftragen Herrn Hasse über den Weg, das mich ratlos zurück läßt. Es geht um einen Friseurbesuch.

TLZ: Mir hat ein Friseur neulich erklärt, er könne mir nicht mehr die Haare schneiden, wenn ich sein DSGVO-Formular nicht ausfüllen würde. Das ist doch Unsinn.
Hasse: Mir ist zumindest nicht klar, welche Daten der Friseur da gemeint haben sollte. Wenn es nur darum geht, jemandem die Haare zu schneiden, werden ja keine Daten erhoben. …

Cut-off_ponytail_(close_in)

By Vive la Rosière - Own work, CC BY-SA 3.0

Dies ist für jemanden, der Schulnoten als datenschutzrechtlich relevant ansieht, eine überraschende Aussage.

Was geschieht denn genau beim Friseur?

Man wartet und bekommt die Haare geschnitten. Dann bezahlt und geht man wieder.

Zurück bleiben die Haare.

Haare sind Körpermaterial und damit biometrische Daten.

Die DSGVO sagt dazu in Artikel 9 (Abs 1)

Die Verarbeitung personenbezogener Daten, aus denen die rassische und
ethnische Herkunft, politische Meinungen, religiöse oder
weltanschauliche Überzeugungen oder die Gewerkschaftszugehörigkeit
hervorgehen, sowie die Verarbeitung von genetischen Daten, biometrischen
Daten zur eindeutigen Identifizierung einer natürlichen Person,
Gesundheitsdaten oder Daten zum Sexualleben oder der sexuellen
Orientierung einer natürlichen Person ist untersagt.

Wie gefährlich Haare sind, mußte schon ein Fussballtrainer erfahren. Man kann also nicht behaupten, die Deutschen™ wüßten nichts davon.

Geht man noch einen Schritt weiter und schaut, was mit den Haaren im Friseursalon so passiert, wird es erst richtig spannend. Echthaar ist bei der Perückenherstellung begehrt. Dazu muß es sortiert aufbewahrt werden, was sich natürlich beim einfachen Trimm nicht lohnt.

Die DSGVO sagt dazu in Art 4 (Abs 6)

"Dateisystem" jede strukturierte Sammlung personenbezogener Daten, die
nach bestimmten Kriterien zugänglich sind, unabhängig davon, ob diese
Sammlung zentral, dezentral oder nach funktionalen oder geografischen
Gesichtspunkten geordnet geführt wird;

Eine sortierte Aufbewahrung von Haaren gehört hier zweifelsfrei dazu.

Und was macht der Friseur dann mit dem Langhaar? Verkaufen. Aber das will ich in Hinblick auf Art 46 DSGVO nicht weiter thematisieren.

Was nicht verkauft wird, wird weggeworfen (gelöscht). Auch dafür gibt es entsprechende Reglungen, wie Art 28 DSGVO, da der Entsorger als Auftragsdatenverarbeiter anzusehen ist.

Warum kreide ich das Herrn Hasse an? Weil er nach Art 35 Abs 2 DSGVO im Rahmen der notwendigen Datenschutzfolgeabschätzung als absegnende Stelle involviert ist.

Ein Kunde kann in seiner bei uns gehosteten Umgebung nicht auf ein Share zugreifen, wenn er es nur mit dem kurzen Namen anspricht. Die Fehlermeldung spricht von fehlenden Zugriffsrechten. Mit den langen Namen (angehängter Domain) geht es aber problemlos. Der Fehler ist eine Verkettung unglücklicher Umstände, beteiligte Parteien sind: Der Kunde, ein Kunde des Kunden, Microsoft, Apple und die IETF.

Problem

Greift man auf das Share mit vollem FQDN zu, gibt es keinerlei Probleme:

smb-full-name

Und so soll es auch mit einem kurzen Namen sein, denn der Kunde mag nicht immer seine eigene Domain hinschreiben. Insbesondere dann nicht, wenn der Kurzname sonst überall funktioniert.

Probiert man also im File-Exporer per UNC auf das Share zuzugreifen, klappt das allerdings nicht. Stattdessen poppt eine Fehlermeldung auf:

smb-permission-denied

Obwohl der Zugriff nicht funktioniert, ist das Share aber eingebunden, wie net use zeigt. Nur der Zugriff klappt nicht.

smb-net-use

Witzigerweise gibt es keinerlei Probleme, wenn man im Explorer den kurzen UNC-Pfad an einen Laufwerksbuchstaben bindet. Das ist bei Laufwerk U: im Bild schön zu sehen.

Die Fehlersuche dieses Phänomens dauerte Wochen:

  • Gruppenrichtlinien wurden geprüft
  • Changelogs der Updates und Hotfixes intensiv studiert
  • Mitschnitte der Netzwerkkommunikation zwischen den beteiligten Servern nebeneinander gelegt (evtl. Paketverlust im Netzwerk?)
  • Andere Shares wurden untersucht (keine Probleme dieser Art)
  • Das Share bekam andere Aliasnamen (und die Probleme waren weg)

Am Ende kristallisierte sich heraus, daß der Name des Shares das Problem darstellt. Schon die Änderung eines einzigen Zeichens lies den Effekt verschwinden. Was war also so speziell an dem Namen?

Nein, es heißt nicht com oder nul, jedoch gibt es Dateiendungen, die diese drei Buchstaben haben. Hat sich evtl. eine Anwendung für diese Zeichenfolge zu übereifrig registriert?

Lösung

Auf die richtige Spur kamen wir, als wir die Namensauflösung komplett mitschnitten. Denn die Maschine versucht beim Zugriff auf das Share DNS-Anfrage an die Nameserver eines Kunden (vom Kunden) zu schicken. WTF?

Wenn ein Windows auf ein reines UNC Share zugreift, benutzt es intern einen anderen (moderneren) Codepfad. Deswegen kommt es da auch prima mit IPv6 klar.

Dieser moderne Code benutzt auch aktuellere Standards, z.B. RFC 6762. Dort heißt es:

this document allows any computer user to elect to give their computers
link-local Multicast DNS host names of  the form: "single-dns-label.local."
In this respect the ".local." suffix is treated no differently from any other
search domain that might appear in the DNS search list.

Die IETF hat die proprietäre Entwicklung von Apple standardisiert und dabei Fallbacks aufs klassische DNS mit eingebaut, um auch bei Mischumgebungen noch funktionsfähig zu sein. Microsoft hat diesen Standard irgendwann implementiert.

Kurz und gut, der Client hat die Namensauflösung per Multicast DNS versucht und einen .local. Namen konstruiert. Den hat er angefragt und bekam eine unerwartete Antwort:

smb-conditional-forwarders

Unser Kunde hat mit seinen Kunden z.T. Active-Directory-Trusts zwecks Singe-Sign-One auf gemeinsame Ressourcen im Einsatz. Inzwischen wird lieber über ADFS gearbeitet, aber die alten Lösungen für Bestandskunden sind nach wie vor aktiv.

Für den AD-Trust müssen sich die Nameserver der beiden Domains gegenseitig erreichen können. Dies wird hier per Conditional Forwarder gemacht, um Eingriffe in den normalen Namensraum zu vermeiden.

In dem vorliegenden Fall, ist der Kurzname exakt der Name der AD-Domain beim Kunden (um .local erweitert). Deswegen glaubte der DNS-Server, eine Antwort zu haben, und schickte dem Client die entsprechende Delegation.

Infolge dessen fragt der Client dann selbst direkt bei den Nameservern des Kunden an, bekommt als eine Antwort eine IP Adresse, zu der er sein SMB-Paket schickt … Permission denied.

Fazit

Eigentlich müßte der Kunde des Kunden seine AD-Domain umbenennen. Ich habe den Namen extra unkenntlich gemacht, weil er durch seine Größe doch zu leicht zuzuordnen ist.

Bleibt als Alternative: Das Share wird umbenannt.

Merke:

  • Benutze niemals die Domain .local für eigene Zonen.
  • Benutze niemals einen Namen, der als .local-Domain irgendwie erreichbar sein könnte.

Nach dem Wechsel auf neuere Hardware (10G) und damit verbunden auch auf den aktuellsten Softwarestand von FreeBSD haben die NAT Kisten sporadisch massive Probleme. Ein glücklicher Zufall gestattete zuerst die Diagnose und dann die Lösung des Problems. CPU Last fällt von 90% (pro Prozeß) auf einstellige Werte.

Spikes

Immer wieder kommt es auf einer NAT Kiste zu akuten Performance-Problemen. Dabei bricht der maximal erreichbare Durchsatz pro TCP-Session auf unter 10Mbps zusammen. Oft ist der Gesamtdurchsatz des Systems auf knapp 200Mbps begrenzt, obwohl da drei mal 10G anstecken. (Für den Anschluß des vierten Interfaces fehlt aktuell ein Rack.)

Im CPU Graphen schaut das dann so aus.

stats-thread-peak

Um kurz nach 18 Uhr hatte die betreffende Maschine ein Lastproblem. Allerdings war es schon nach wenigen Minuten wieder weg.

In den meisten Fällen bisher waren die Lastspitzen noch deutlich kürzer, so daß man sie in diesem Graphen nicht mal richtig sieht.

Da allerdings das Problem nur sporadisch auftritt, nicht reproduzierbar ist, und die Beeinträchtigung der Kunden auch nicht lange genug anhält, um zu spezifischen Störungsmeldungen zu führen, war bisher eine Fehlersuche ergebnislos.

Glückliche Zufälle

Gestern erst hatte ich im Zusammenhang mit FreeBSD ein WTF-Erlebnis, das mit NAT zusammenhängt.

Und heute zeigte eine Maschine erstmals einen stabilen Fehlerzustand.

stats-thread-bummer

Wow, was für ein gewaltiger Vorfall! Endlich mal Zeit zum Debuggen.

Mit dem Hintergedanken des gestrigen Erlebnisses im Kopf fiel irgendwann in einem glücklichen Mitschnitt auf, daß es Pakete gibt, bei denen Quell- und Ziel-IP gleich sind. Noch dazu sind diese IPs auch die öffentlichen IPs des NAT.

Ganz offensichtlich kommt es vor, daß irgendein kruder Netzscanner Pakete schickt, die das NAT als gültig ansieht und nattet. Dabei entstehen Pakete, bei denen Quell- und Ziel-IP gleich sind. Und diese landen dann wieder beim NAT. Dabei entstehen Pakete, bei denen Quell- und Ziel-IP gleich sind. Und diese landen dann wieder beim NAT. Dabei entstehen Pakete, bei denen Quell- und Ziel-IP gleich sind. Und diese landen dann wieder beim NAT. Ähm, das Prinzip sollte klar sein.

Also kurz eine Firewallregel hinzugefügt, die Pakete von NAT-IPs an NAT-IPs verwirft.

Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:63647 178.19.233.4:57691 in via vlan94
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:64584 178.19.233.4:57691 in via vlan94
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny TCP 91.137.21.7:42512 91.137.21.7:3888 in via vlan94
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:62012 178.19.233.4:49655 in via vlan94
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:6763 178.19.233.4:57691 in via vlan94
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny TCP 91.137.17.4:14938 91.137.17.4:64906 in via vlan94

Und schon fällt die CPU Last der Netzwerk-Interrupts auf einstellige Prozentzahlen.

Fazit

Ursächlich für den Vorfall ist ein Wechsel von quagga zu bird.

Früher mußten die einzelnen NAT-IPs lokal geroutet werden, nun genügt es, die betreffenden Netze im OSPF zu announcen und sie per ipfw auf den Uplinkports abzugreifen. Eine lokale Route gibt es also nicht mehr.

Sollten solche Pakete trotzdem lokal erzeugt werden, verlassen sie das Gerät und kommen vom nächsten Router wieder zurück. Dabei werden sie wieder dem NAT vorgeworfen.

Es ist zwei glücklichen Zufällen zu verdanken, dieses Problem überhaupt finden zu können: Weil es lange genug andauerte und das betreffende Muster gerade frisch bekannt war.

Und nun können die Kisten endlich mal richtig Last aufnehmen. Ich bin gespannt.

Wir sind alle mit Nokia aufgewachsen, was logischerweise beim Smartphone bei Lumia endete. Die Teile sind zuverlässig, funktional, leicht reparierbar und bekommen langfristige Softwareunterstützung. Ideal, auch wenn sie (aus)sterben.

Heute hat sich der Kleine jammernd beklagt, dass sein 520 komplett kaputt sei. Es zeige nur noch einen blauen Bildschirm mit englischer Schrift an. Daraus schlau werde man aber daraus nicht.

WP_20180725_16_54_38_Pro

Nunja, die Fehlermeldung ist tatsächlich fast unbrauchbar:

  • Das Gerät ist kaputt.
  • Es fehlt die zentrale Konfiguration.
  • Es fehlt eine Datei im Filesystem (oder das ganze Filesystem?)
  • Man möge ein Reparatur-Tool benutzen oder den Hersteller bemühen.

Erstaunlicherweise ist das Windows Device Recovery Tool leicht zu finden und zu benutzen.

Man schließt das kaputte Handy per USB an und hofft das Beste.

wp-detect

Selbstverständlich passierte nichts. Auch nicht, wenn man explizit das Modell vorgab.

Grund dafür war ein USB-Ladekabel, das eben kein Datenkabel war. Diese Teile gehören zerschnitten und zerstört, alternativ thermisch dem Netzteil zugeordnet.

Hat man das richtige Kabel, erkennt der PC auch ein USB-Gerät:

wp-boot-manager

Beim Booten kann man per USB sozusagen ins Handy-BIOS abbiegen. Und das ist die Voraussetzung für das Recovery Tool. Es meldet dann auch gleich:

wp-select

Damit ermittelt das Tool die aktuellste passende Firmware (das Handy selbst hatte keine mehr) und läd sie nach.

wp-download

Der Prozess ist durchaus etwas langwierig, aber dann kommt schon die Installation selbst:

wp-installation

Anschließend bootet das Handy und ist wie frisch aus dem Werk.

wp-auswahl-image

Das ist keine Übertreibung: Die installierte Version ist ein nicht normal verfügbares Image von Windows Phone 8.1, das für die polnische T-Mobile vorgesehen ist.

Bei der Einrichtung muss man dann halt die Sprache von Polnisch (statt Englisch) auf Deutsch umstellen, die Sprachassistenzpakete auswechseln und zwei extra Apps löschen.

Das Kind ist ist jedenfalls zufrieden.

Was mich aber erfreut, ist der völlig problemlose Support für ein solches Altgerät. Selbst für die noch älteren Nokias gibt es entsprechende Recovery Tools. Auch die Installation der bisherigen Apps verlief problemlos. Kein abgeschalteter Store, kein Rumzicken mit RMA-Einsendungen.

Es tut einfach. Und das ist leider selten geworden. Danke.

Manchmal überrascht einen eine Trivialität. Ich wollte das Routing einer Server-IP prüfen, aber der Trace wurde zu mir zurück reflektiert. Wie geht das?

Wunder

traceroute to 178.19.224.48 (178.19.224.48), 30 hops max, 40 byte packets
 1  switch1-9-4-1-vl52.net.iks-jena.de (217.17.197.11)  1.470 ms  1.372 ms  1.304 ms
 2  turm1-g001.net.iks-jena.de (217.17.197.49)  0.382 ms  0.438 ms  0.363 ms
 3  rudo8-t001-116.net.encoline.de (5.102.160.98)  0.613 ms  0.574 ms  0.566 ms
 4  switch3-v93.net.encoline.de (5.102.160.161)  1.465 ms  1.141 ms  1.170 ms
 5  server16-vlan58.net.encoline.de (5.102.160.132)  0.567 ms  0.538 ms  0.541 ms
 6  switch4-v94.net.encoline.de (5.102.160.178)  2.181 ms  1.469 ms  1.686 ms
 7  server16-vlan94.net.encoline.de (5.102.160.185)  0.641 ms  0.635 ms  0.575 ms
 8  switch2-v58.net.encoline.de (5.102.160.129)  9.887 ms  3.478 ms  1.380 ms
 9  rudo7-t000-123.net.encoline.de (5.102.160.90)  0.879 ms  0.740 ms  0.721 ms
10  turm1-g001-116.net.iks-jena.de (5.102.160.99)  0.991 ms  0.942 ms  1.012 ms
11  * * *
12  nat-178-19-224-48.net.encoline.de (178.19.224.48)  1.123 ms  1.052 ms  1.025 ms

Der Trace geht raus, kehrt um, kommt zurück und am Ende meint er das Ziel erreicht zu haben.

Dabei trifft er sogar bestimmte Router mehrfach. Das ist deswegen verwunderlich, weil doch die Router ihre Entscheidung allein anhand der Zieladresse fällen. Wie kann also das Paket in verschiedene Richtungen geroutet werden?

Zunächst erst einmal handelt es sich nicht um ein lokales Phänomen, sondern es funktioniert auch von anderen Quellen aus.

traceroute to 178.19.224.48 (178.19.224.48), 30 hops max, 60 byte packets
...
 4  inexio2.gw.network.manitu.net (89.238.127.62)  4.593 ms  4.594 ms  4.592 ms
 5  209-096-244-077.ip-addr.inexio.net (77.244.96.209)  7.633 ms  7.634 ms  7.642 ms
 6  DE-CIX1.de.lambdanet.net (80.81.193.74)  7.605 ms  7.358 ms  6.739 ms
 7  ae2.irt2.fra25.de.as13237.net (217.71.96.45)  7.881 ms  7.878 ms  7.584 ms
 8  ae5.irt1.han87.de.as13237.net (217.71.96.30)  13.407 ms  13.380 ms  13.390 ms
 9  ae7.irt1.ber02.de.as13237.net (217.71.96.133)  16.610 ms  16.613 ms  16.607 ms
10  bb-erf-02-loc.netz.netkom-line.net (109.73.31.198)  213.352 ms  213.364 ms  213.361 ms
11  tnk-ilm-001-loc.netz.netkom-line.net (109.73.31.195)  22.149 ms  20.946 ms  20.579 ms
12  109.73.31.141 (109.73.31.141)  147.983 ms  147.987 ms  147.974 ms
13  tnk-jen-001-loc.netz.netkom-line.net (109.73.31.193)  19.504 ms  19.453 ms  19.471 ms
14  tnk-jen-001-ipt.netz.netkom-line.net (109.73.31.194)  19.468 ms  19.468 ms  19.467 ms
15  rudo7-t010.net.encoline.de (5.102.160.105)  33.994 ms  34.003 ms  34.002 ms
16  switch2-v123.net.encoline.de (5.102.160.91)  34.350 ms  34.407 ms  34.573 ms
17  server16-vlan58.net.encoline.de (5.102.160.132)  33.875 ms  33.879 ms  33.866 ms
18  switch4-v94.net.encoline.de (5.102.160.178)  34.753 ms  35.605 ms  35.596 ms
19  server16-vlan94.net.encoline.de (5.102.160.185)  34.362 ms  34.259 ms  34.179 ms
20  switch2-v58.net.encoline.de (5.102.160.129)  34.800 ms  35.279 ms  34.905 ms
21  rudo7-t000-123.net.encoline.de (5.102.160.90)  34.440 ms  34.203 ms  34.452 ms
22  rudo5-t001-123.net.encoline.de (5.102.160.89)  34.228 ms  34.449 ms  34.435 ms
23  ar2.ber.de.colt.net (213.61.70.177)  55.706 ms  55.705 ms  55.674 ms
24  212.36.135.22 (212.36.135.22)  55.909 ms  56.438 ms  56.417 ms
25  212.36.135.22 (212.36.135.22)  55.398 ms  55.416 ms  55.389 ms
26  * * *
27  * * *
28  * * *
29  nat-178-19-224-48.net.encoline.de (178.19.224.48)  68.590 ms  68.544 ms  68.691 ms

Wow. Hin- und Rückrouting in einem Trace! Man sieht sehr schön den asymmetrischen Rouingweg.

Aber was passiert da?

Schnüffeln

Die Ursache sollte ausschließlich am angesprochenen Server zu suchen sein. Alles andere wäre eine grobe Überraschung, denn dann müßten die Geräte im Transportweg irgendeine Manipulation vorgenommen haben.

Also ein Mitschnitt auf den Außeninterfaces des betroffenen Servers aktiviert:

13:39:51.074580 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 13, length 20
13:39:51.074601 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.077408 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 14, length 20
13:39:51.077414 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.077939 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 15, length 20
13:39:51.077944 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.078590 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 16, length 20
13:39:51.079237 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.082388 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 17, length 20
13:39:51.084253 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.084855 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 18, length 20
13:39:51.088146 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.088802 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 19, length 20
13:39:51.088848 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.092134 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 20, length 20
13:39:51.092176 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.092892 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 21, length 20
13:39:51.092934 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.093756 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 22, length 20
13:39:51.093774 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 22, length 20
13:39:51.097201 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.100803 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 23, length 20
13:39:51.100823 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 23, length 20
13:39:51.101499 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.102261 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 24, length 20
13:39:51.102280 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 24, length 20
13:39:51.102924 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.103742 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 25, length 20
13:39:51.103763 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 25, length 20
13:39:51.103870 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.106558 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 26, length 20
13:39:51.106577 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 26, length 20
13:39:51.106687 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.107389 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 27, length 20
13:39:51.107408 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 27, length 20
13:39:51.107510 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.108284 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 28, length 20
13:39:51.108302 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 28, length 20
13:39:51.108652 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.111847 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 29, length 20
13:39:51.111866 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 29, length 20
13:39:51.112220 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.113013 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 30, length 20
13:39:51.113032 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 30, length 20
13:39:51.113386 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.114062 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 31, length 20
13:39:51.114080 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 31, length 20
13:39:51.115606 IP 217.17.197.43 > 217.17.192.34: ICMP time exceeded in-transit, length 36

Man sieht sehr schön, wie anfangs die Echo-Pakete mit einem Timeout beantwortet werden.

Kurz darauf (ab Sequenznummer 22) tauchen plötzlich Echo-Pakete auf, bei denen Quell- und Ziel-Adresse vertauscht sind. Diese entstehen offenbar direkt nach dem Eingang des ersten Paketes.

Nun dient die Kiste ein (Carrier Grade)-NAT. Ihr Zweck ist es also Pakete umzuschreiben und zwar so, daß möglichst wenig Pakete verloren gehen. Schließlich dient NAT ja dazu, Verbindungen zu ermöglichen! Eine Firewall oder Paketfilter würde Pakete verwerfen. NAT dagegen muß so gut wie möglich raten, wo das Paket eigentlich hin soll.

In diesem Fall geht das NAT systematisch vor:

  • Es nattet die fremde Quell-Adresse auf die eigene öffentliche IP.
  • Und es nattet die eigene öffentliche Ziel-IP zu – tja wohin, achja, da ist ja ein ganz frischer Eintrag in der NAT Tabelle …

Fertig ist der Spiegel.

Gefährlich?

Kann man das mit allen Protokollen machen? Wenn ja, könnte man trivial unter falscher Flagge segeln, oder?

Tracing the path to 178.19.224.48 on TCP port 80, 30 hops max
 1  switch1-9-4-1-vl4.net.iks-jena.de (217.17.192.125)  6.742 ms  2.125 ms  1.139 ms
 2  turm2-g001-5.net.iks-jena.de (217.17.197.50)  0.228 ms
    turm1-g001.net.iks-jena.de (217.17.197.49)  0.350 ms
    turm2-g000-3.net.iks-jena.de (217.17.197.34)  0.265 ms
 3  rudo8-t001-116.net.encoline.de (5.102.160.98)  0.449 ms  0.468 ms  0.423 ms
 4  switch3-v93.net.encoline.de (5.102.160.161)  1.414 ms  1.570 ms  2.359 ms
 5  server16-vlan58.net.encoline.de (5.102.160.132)  0.489 ms  0.431 ms  0.418 ms
 6  switch4-v94.net.encoline.de (5.102.160.178)  1.443 ms  1.166 ms  1.921 ms
 7  server16-vlan94.net.encoline.de (5.102.160.185)  0.429 ms  0.473 ms  0.444 ms
 8  switch4-v94.net.encoline.de (5.102.160.178)  14.355 ms  2.695 ms  1.462 ms
 9  server16-vlan94.net.encoline.de (5.102.160.185)  0.473 ms  0.495 ms  0.465 ms
...

Nein, man kann nicht. Und das ist gut so™.