Die alten Herren von der Piratenpartei
Ein Kunde berichtete über eine Nichterreichbarkeit des Webservers der Piratenpartei. Die Störung sah aus wie ein Routingproblem, aber es war viel viel schlimmer.
Zusätzlich zu der Nichterreichbarkeit der Webseite waren auch zwei Traceroutes mitgeliefert worden. Einer aus Kundensicht und einer vom Webserver aus. Die sehen so aus (IP Adresse des Kunden durch die eines Routers ersetzt)
traceroute from 178.19.71.117 to 178.19.224.1 1 178.19.71.1 (178.19.71.1) [AS29551] 0.673 ms * * 2 * * * 3 * * * 4 80.81.193.74 (80.81.193.74) [AS6695] 0.660 ms * * 5 * * * 6 * * 217.71.99.134 (217.71.99.134) [AS13237] 8.215 ms 7 109.73.31.194 (109.73.31.194) [AS196714] 8.227 ms * * 8 * * * 9 * * *
Sowie
traceroute from 178.19.224.1 to 178.19.71.117 1 rudo1-g01-115 (217.17.207.161) 18.793 ms 1.234 ms 5.662 ms 2 NUE-2.de.lambdanet.net (217.71.100.33) 4.153 ms 4.303 ms 4.192 ms 3 xe0-0-0.irt1.fra44.de.as13237.net (217.71.96.73) 7.408 ms 7.421 ms 7.426 ms 4 decix.fra2.tng.de (80.81.192.83) 12.095 ms 12.027 ms 12.094 ms 5 t4-1.decix.rt02.of.aixit.net (83.141.1.187) 12.080 ms 12.286 ms 12.279 ms 6 v7.rt03.boe.aixit.net (83.141.0.249) 12.015 ms 12.500 ms 13.041 ms 7 v3-rt01.boe.aixit.net (83.141.1.97) 12.021 ms 12.247 ms 12.502 ms 8 * * * 9 * * *
Führt man Traces von anderen Systemen aus, so scheint alles ok zu sein.
Nach direktem Kontakt zu einem Admin der BundesIT (vielen Dank für die Geduld mit meinen doch sehr erstaunten Fragen) stellte sich heraus.
- Eingehende ICMP-Pakete sind bei der Firewall der Piratenpartei rate-limited.
- Einige Server dort hatten die falsche Netzmaske, deswegen glaubte der Webserver, die Antworten im lokalen Netz ausliefern zu können.
Wie kommt man zu einer falschen Netzmaske? Ganz einfach: Die Server waren classful konfiguriert. 178.19.224.1 und 178.19.71.117 liegen nun mal im gleichen /16 (ehemals Class-B Netz).
Ob des Ratelimits weist der Traceroute die Sterne unterwegs auf: Die Antworten erreichen die tracende Maschine gar nicht.
Nebenbei stellte sich auch heraus, warum Ping komplett gesperrt und ICMP rate-limited ist: Man könnte ja herausbekommen, welche IPs benutzt werden.
Und das Problem wird schon länger gesucht, wie eine Diskussion auf Twitter zeigt.
- Ich erhalte vom Kunden eine Fehlerbeschreibung (mehrtägige Nichterreichbarkeit).
- Der Fehlerbeschreibung liegen beiden Traces und die Aussage "Peering Problem" bei.
- Ich muß annehmen, daß die Traces mit dem Problem zu tun haben und im Rahmen des Analyse, die zu "Peering Problem" geführt hat, entstanden sind.
- Ich muß weiterhin davon ausgehen, daß ein als akut beschriebenes Problem nicht zwischenzeitlich mehrfach gefixt und anderweitig neu verursacht wurde.
Der Trace von einem System in der Nähe des Webservers aus zeigt massive Paketverluste quer durch alle Hosts. Die Symptome dieses Paketverluste lassen sich am einfachsten (und in der Regel auch zutreffend) durch einen ICMP (Rate-Limit) Filter kurz vor der tracenden Stelle erklären.
Erst nachdem lokale Probleme für meine Begriffe (ich mache zuviele Fehler selbst, um sie sofort anderen in die Schuhe zu schieben) ausgeschlossen werden konnten, habe ich das Problem auf verschiedene Weisen nachgestellt und dann gezielt mit Peers und Uplinks gesprochen.
Am Ende waren wir uns alle einig, daß die Antwortpakete auf TCP/80 Anfragen an den Webserver zwar hingeschickt, aber nicht eingehend beobachtet werden können. Wohl aber kommen die letzten Pakete von Eurem ISP aus dem Tcptraceroute beobachtbar zurück.
Erst dann habe ich versucht, einen Kontakt zu jemanden zu finden, der sich um den Webserver und das Netz kümmert. Ich bin zu altmodisch, um die von der BundesIT vorgeschlagenen Kommunikationswegen nutzen zu können. IRC, Usenet, Web, E-Mail und Telefon sind meine typischen Kommunikationsformen. Außerdem hatte ich nicht vor, einen Rattenschwanz an zusätzlichen Problemen loszutreten, nur weil ich die offiziellen Kanäle benutze und dort das passende Shibboleth nicht kenne.
Glücklicherweise gab es Leute, die über ein oder zwei Ecken dann jemanden erreichten, der die falsche Netzmaske bemerkte. Auf diese Weise konnte das Problem gelöst werden. Hier hätte Schluß sein können.
Als ich aber so meine Erkennisse (alles "educated guess") kommunizierte, habe ich Zustimmung zur Analyse und Entsetzen über die Art des Umgangs mit diesem Problem erleben dürfen. Deswegen habe ich darüber geblogt: Weil es für mich unfaßbar ist, das mit so viel Unverstand in produktiven Netzen gestochert wird.
Deine Kommentare zeigen mir zweierlei:
1) Du mußt ruhiger werden. Alle machen Fehler. Oft genug noch viel haarstäuberendere als Classful Addressing. Aber Du bist auf einer öffentlichen, ja politischen, Bühne. Dort kann man sich diese Entgleisungen nicht leisten.
2) Das, was Du technisch für richtig oder unrichtig hälst, wurde von anderen vor Deiner Zeit erdacht, erstellt und benutzt. Diese Leute waren nicht dumm oder lebten nur in ihrem Elfenbeintum. Es lohnt sich herauszufinden, warum Dinge sind, wie sie sind. Vor allem, bevor man sie verändert oder (wie Du) wegfiltert.
- dein erster hier veröffentlicher Traceroute zeigt, das wir von der bemängelten IP dich nicht erreichen konnten. ein "classfull" Problem war es aber auch nicht, da der trace offensichtlich geroutet wurde
-- Ergo: Es GAB ein Peering Problem
- Das traces aus anderen Ecken der Welt gehen ist bei einem Peering Problem nicht weiter verwunderlich
- Nachdem wir gestern noch einmal die Fehlermeldung erhielten, haben wir noch einmal, den selben Test gemacht. Und erhielten diesmal ein anderes Bild, denn das Routing hat schon bei uns nicht funktioniert. Wir haben das Problem behoben und seit dem geht alles wieder.
-- Ursache war eine Änderung NACH dem 11.1
Ich weiß ja nicht wo du deine Infos her beziehst, und wie du auf die Idee kommst, das zum selben Zeitpunkt jemals ein Trace ging wärend am anderen Ende keine Daten angekommen sind ( aus den Traces lies sich das nicht wirklich schließen, die sehen aber zugegeben seltsam aus)
Und nun nur noch kurz zu den "Vorwürfen" in den Kommentaren:
- Es gibt kein IDS, aber Idioten die nicht nur -PN vergessen sondern auch gleich noch ein -sV anmachen. Um das zu erkennen reicht die Log eines Dienstes ...
- Ja, ich bin die selbe Person die auch TheAnswer online gestellt hat, nun kann ich dich auch wieder zuordnen.
DU bist doch die Person die Behauptet ein VPN wäre Blödsinn und man hängt natürlich alle Systeme incl. Testumgebungen oder Windows-Systeme mit Personenbezogenen Daten und einem offenenen RDP Port direkt ins Netz!
Und BTW: Wenn ich nachts zum 30x mal an einem Tag nenn dämlichen nmap Portscan auf die gesammte Range entdecke mach ich nun mal IMCP8 dicht.
</blockquote>
Dämlich ist es, ein IDS auf dem externen Interface einer Firewall laufen zu lassen. Genauso dämlich wie nmap ohne "-Pn" zu verwenden - wegen der unbedarften Admins, die ping sperren.
Die Aussage, daß bei Euch öffentliche Adressen nur auf der Firewall vorliegen, verwundert mich allerdings wirklich. Wie kann dann ein Traceroute aus Eurem Netz funktionieren, während der daneben stehende Server die Daten nicht zustellen kann? Habe Ihr mehrere Firewalls und den Test aus einem ganz anderen Netzsegment gemacht? Warum debuggt Ihr das Problem, daß seit dem 11.1. bei Euch bekannt ist (siehe Twitter), nicht dort wo es auftritt?
BTW: Bist Du die gleiche Person, die https://piratenpad.de/p/PiratenITVerriss-TheAnswer geschrieben hat? Oder handelt es sich bei dem Pseudonym um einen Role Account?
Und BTW: Wenn ich nachts zum 30x mal an einem Tag nenn dämlichen nmap Portscan auf die gesammte Range entdecke mach ich nun mal IMCP8 dicht.
Und was eine Classfull Theorie betrifft: Wir haben alle öffentlichen IP's NUR, ich wiederhole NUR auf den Firewalls.
Also, stell das doch bitte einfach mal deutlich dar, dass du nur geraten hast.
Danke.
Was macht eigentlich so ein 'gegen ping gesichertes Netz', wenn man ein paar 'Päckchen' mehr schickt? Etwa so:
#!/bin/bash
clear
echo "Thou shalt not ..."
echo "...do anything illegal with this little script!"
read -p "target IP or domain.tld ? " target
read -p "packetsize in bytes (0-65535)? " packetsize
read -p "how many instances ? " instances
sleep 1
echo "the instances will now be started sequentially ... let´s let the shit hit the fan ;3"
counter=0
while [ "$counter" != "$instances" ]; do
nohup>/dev/null ping -s $packetsize -i 0.3 $target &
counter=`expr $counter + 1`
echo "instance $counter is up and firing ... "
done
echo "mission accomplished ;3"
echo "all instances are now firing as they´re told ..."
echo "if you´d like to stop the fire ..."
echo "just press ALT+F2 and type »killall ping« and press ENTER ;3"
sleep 2
echo "bye!"
sleep 5
Kann man dann vielleicht wenigstens eine Fehlermeldung herauskitzeln? Habe bislang nur mit virtuellen Maschinen herumspielen können, weil mir zum spielen in der 'Wildnis' die notwendige Einwilligung fehlte, konnte aber lokal bis 40G Bit/s Last erzielen... da war dann auch für Fehlermeldungen kein Platz mehr. ;)
Aber grundsätzlich würde mich schon interessieren, wie man ggf. die IPs der 'Star-Hops' herausfinden kann, insbesondere im Kontext von QoS bei mobilen Internetanschlüssen. Ich bin auch für freundliche RTFM-Hinweise dankbar - mit Angabe von zu suchenden Stichworten oder Literaturverweisen - ich lerne gern (selbstständig!) dazu. Danke!
So long!
Vielleicht habt ihr auch eine ganz andere Infrastruktur und es war ein interner Router. Du kannst ja mal die Netzpläne online stellen.
Alle 12 Kommentare anzeigen