Ja, ich weiß, Ihr könnt es nicht mehr lesen, der xte Mailserver der keine TLS 1.2 kann, nur leider hat der hier eggs.gnu.org eine wichtige Rolle, der handelt nämlich Emails für gnu.org . Kein TLS 1.2 , keine Emails mehr aus Europa.
„.. und dabei ist FOSS & TLS 1.2 kein Widerspruch.“
Trying TLS on eggs.gnu.org[209.51.188.92:25] (10):
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
wenn man mal genauer hinsieht mit : „openssl s_client -connect eggs.gnu.org:25 -starttls smtp -tls1“
Subject=/CN=eggs.gnu.org …. New, SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA …. 250 HELP
sieht dann auch, daß der Cipher noch aus SSLv3 Zeiten stammt, was nicht verwundert, weil TLS 1.0 nur SSLv3 mit SNI Support ist.
Falls jemand von Euch jemand den GNU Leuten Emails schicken will, machts gleich in Klartext 😀
Fangen wir mal mit der einfachsten Fragestellung im Netzwerk an:
Habe ich überhaupt ein Netz ?
Dazu fragen wir den Netzwerkstack( ab jetzt nur noch TCP/IP Stack) von Linux mit „ip link“, ob wir überhaupt eine aktive Netzwerkkarte haben, wie man sich denken kann, wird das ohne Netzwerkkarte ein Problem.
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 40:66:3e:21:1a:76 brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:0a:cf:07 brd ff:ff:ff:ff:ff:ff
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:0a:cf:07 brd ff:ff:ff:ff:ff:ff
Wir erhalten eine Liste aller nützlichen Interface (Netzwerkadapter) mit Ihrem jeweiligen Status.
Das hier als 1 bezeichnete Interface heißt „lo“ und ist das Loopback Device besser bekannt mit seiner StandardIP 127.0.0.1 . Es ist von außen nicht erreichbar und nur für intere Zwecke da. Ein Unixrechner ohne 127.0.0.1 ist mir nicht bekannt 😉 Das Loopback Device wird für diverse Zwecke gebraucht u.a. das mounten von Truecryptcontainern und Netzwerktunneln.
An zweiter Stelle kommt in unserer Liste das „enp2s0“ früher mal als „eth0“ bezeichnet. Heute kommen die Bezeichnungen vom Kernel und zwar nicht direkt zufällig, aber meisten eine Zusammenstelung aus Devicenamen und Ports des Chips der für das Interface verantwortlich ist. Es kann bei jedem anders aussehen, wenn es Lust hat. Man kann es über den „udevd“ auch wieder in eth0 ummünzen, wenn es einem den Aufwand Wert ist.
Für uns ist es das wichtigste Interface, denn es stellt unsere Netzwerkkarte dar. Der „State UP“ meint, daß es „up and running“ ist, also eingeschaltet und funktioniert und das ist genau was wir wollen.
CHECK: Karte vorhanden und aktiv.
Schauen wir uns das Interface genauer an. Dazu brauchen wir „ifconfig“ , es geht auch mit „ip“, aber warum sich quälen 😉
Dieser Anzeige können wir entnehmen, daß unsere IP 192.168.123.234 ist, unsere Netzwerkmaske 255.255.0.0 und wie unsere MAC Adresse lautet: 40:66:3e:21:1a:76 . Das ist konkret nicht wichtig, aber wenn Ihr mal Probleme habt einen Rechner im LAN zu erreichen, ist die MACADRESSE der Netzwerkkarte extrem wichtig.
Wie man auch sehen kann, gibt es eine IPv6 Adresse, aber die ist quasi fiktiv, weil nicht es gar nicht konfiguriert ist.
CHECK: Wir haben eine IP Adresse auf der Netzwerkkarte und eine korrekt Netzwerkmaske!
Nun prüfen wir noch, ob die Netzwerkkarte überhaupt irgendwo angeschlossen ist ( Klar geht das von Innen) :
$ ethtool enp2s0 | grep -i detected
Link detected: yes
Stände da jetzt „no“ , wäre kein Kabel drin, bzw. die Gegenstelle z.B. Router / Switch usw. nicht eingeschaltet.
CHECK: Link detected! Die Karte ist mit einer anderen Netzwerkkarte über ein Kabel verbunden!
Ping & Pong ?
Mit dem Befehl Ping kann man alle Rechner im LAN „anpingen“, also anstupsen, die im gleichen Netzwerksegment liegen. Dies meint, daß Sie in der Netzwerkmaske unserer Netzwerkkarte ihre IP Adresse haben UND selbst eine Netzwerkmaske haben, die unsere IP einschliesst. Wie man das berechnet, könnt Ihr im Netz nachlesen.
Für das Beispiel oben war die Netzwerkmaske 255.255.0.0 was meint : mußgenaustimmen.mußgenaustimmen.egal.egal , womit 192.168.0.0 -> 192.168.255.255 abgedeckt sind. Also pinge ich jetzt mal meinen Router an:
$ ping 192.168.123.1
PING 192.168.123.1 (192.168.123.1) 56(84) bytes of data.
64 bytes from 192.168.123.1: icmp_seq=1 ttl=64 time=0.428 ms
64 bytes from 192.168.123.1: icmp_seq=2 ttl=64 time=0.332 ms
64 bytes from 192.168.123.1: icmp_seq=3 ttl=64 time=0.333 ms
64 bytes from 192.168.123.1: icmp_seq=4 ttl=64 time=0.324 ms
64 bytes from 192.168.123.1: icmp_seq=5 ttl=64 time=0.354 ms
64 bytes from 192.168.123.1: icmp_seq=6 ttl=64 time=0.406 ms
Wunderbar, er antwortet UND es kommt nicht zu Aussetzern bei der Sequenznummer, das würde nämlich ein Durchsatzproblem im Netz anzeigen. Die Zeitangabe bezeichnet die Laufzeit des Pakets das wir losgeschickt haben, bis wir eine Antwort darauf hatten. Es gilt: Je kleiner, je besser. Wenn Zeiten vereinzelt nach oben Ausreisser haben, ist was im Netz los und der Durchsatz stimmt nicht. Das könnte dann z.b. „fremde“ Datenströme im LAN anzeigen oder einen ausgelasteten Prozesser ( auf der Gegenseite ) anzeigen. Da gibt es leider einiges an Möglichkeiten.
CHECK: Der Router ist erreichbar!
Traceroute
Wir gehen mal davon aus, daß der Router ok ist und die DSL Strecke auch. Jetzt will man aber z.b. testen, ob es auf der Strecke zum Lieblingsserver ein Problem gibt. Da ist Traceroute bzw. ein Derivat davon namens MTR Eurer Freund.
Die Loss Spalte zeigt hier 0.0% für „Alles OK “ an. Steht hier mehr als nur 0.0 , deutet das auf Probleme beim Datentransport von Paketen an dieser Stelle im Netz hin.
Hinweis: Jeder Rechner auf dieser Welt hat einen eigenen Weg zum Ziel. Wie Bergbäche zu Flüssen werden, so werden auch einzelne Benutzer eines DSL Anbieter vom Bach zum Fluß nur um am Ende in einen großen Teich zu fliessen. Deswegen kann es für den einen PC zu einem Problem kommen, wo sein Nachbar oder irgendwer anders kein Problem hat einen Server zu erreichen. Das ist NORMAL! Glaubt einem beim Telefonsupport zwar keiner, ist aber trotzdem so 🙂
CHECK: Der Server ist erreichbar ohne Paketverluste!
Wenn der Euch jetzt für Webanfragen nicht antwortet, will oder kann er vielleicht grade nicht . Jedenfalls liegt das nicht mehr in Eurer Hand.
Datenströme erfassen mit TCPDump
Ab hier müssen wir wieder ROOT User auf unserem Rechner werden, sonst klappt das nicht.
TCPDump kann Datenströme von der Netzwerkkarte abgreifen und anzeigen bzw. auf die Platte schreiben. Diverse Filter erlauben es, nur das zu sehen, was einen Interessiert. Hier im Beispiel den Aufruf von meinem Blog:
# tcpdump -n host s120.resellerdesktop.de and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:37:22.112794 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [S], seq 325157599, win 29200, options [mss 1460,sackOK,TS val 18499715 ecr 0,nop,wscale 7], length 0
14:37:22.146706 IP 83.246.80.133.http > 192.168.123.234.40802: Flags [S.], seq 2632340454, ack 325157600, win 28960, options [mss 1452,sackOK,TS val 3762553727 ecr 18499715,nop,wscale 7], length 0
14:37:22.146779 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 18499749 ecr 3762553727], length 0
14:37:22.146854 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [P.], seq 1:97, ack 1, win 229, options [nop,nop,TS val 18499749 ecr 3762553727], length 96: HTTP: GET / HTTP/1.1
14:37:22.180314 IP 83.246.80.133.http > 192.168.123.234.40802: Flags [.], ack 97, win 227, options [nop,nop,TS val 3762553761 ecr 18499749], length 0
14:37:22.181118 IP 83.246.80.133.http > 192.168.123.234.40802: Flags [P.], seq 1:456, ack 97, win 227, options [nop,nop,TS val 3762553762 ecr 18499749], length 455: HTTP: HTTP/1.1 302 Found
14:37:22.181170 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [.], ack 456, win 237, options [nop,nop,TS val 18499783 ecr 3762553762], length 0
14:37:22.181429 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [F.], seq 97, ack 456, win 237, options [nop,nop,TS val 18499784 ecr 3762553762], length 0
14:37:22.214648 IP 83.246.80.133.http > 192.168.123.234.40802: Flags [F.], seq 456, ack 98, win 227, options [nop,nop,TS val 3762553796 ecr 18499784], length 0
14:37:22.214705 IP 192.168.123.234.40802 > 83.246.80.133.http: Flags [.], ack 457, win 237, options [nop,nop,TS val 18499817 ecr 3762553796], length 0
Die Uhrzeit mit Microsekunden dürfte noch erkennbar sein, dann folgt das Protokoll „IP“ (ja, gibt noch mehr) , es folgt die QuellIP mit Port und das Ziel mit Port und was danach kommt, sprengt den Rahmen des Artikels, aber so sieht eine Datenübertragung wirklich aus 🙂
Wenn wir jetzt mal sehen wollen, was da übertragen wird, schalten wir mit „-X“ den Inhalt ein:
Alles was man nicht in Klartext lesen kann, sind meistens Optionen innerhalb des IP Datenpakets. Im obigen Fall handelt es sich eindeutig um TCP Datenverkehr. Wer sich dafür interessiert: hier gibt es mehr
Wie man in dem Dump oben sehen kann, wird HTTP in Klartext übermittelt. Damit keine geheimen Daten verloren gehen, wurde HTTPS erfunden. Wer sich die Mühe macht und den Datensalat oben zusammen setzt, wird das hier sehen:
HTTP/1.1 302 Found
Date: Wed, 21 Sep 2016 12:44:14 GMT
Server: Apache/2.4.18 (Fedora) OpenSSL/1.0.1k-fips
Location: https://marius.bloggt-in-braunschweig.de/
Content-Length: 225
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://marius.bloggt-in-braunschweig.de/">here</a>.</p>
</body></html>
Genau, daß ist einfach die Umleitung von HTTP auf HTTPS.
TCPDump kommt immer dann zum Einsatz, wenn man sehen will, was wirklich über die Leitung gegangen ist. Der Browser behauptet zwar, daß X=U ist, aber sagte das auch der Server so ? 😀
Zurück zu den lokalen Tools: iptraf-ng
IPtraf ist eine wahre Schatzkiste an unterschiedlichen Funktionen. Es zeigt live an, „wer mit wem redet“, Statistiken über die Häufigkeit von Paketen und wer vielviel Daten transportiert hat. Alles zu erklären sprengt genau wie bei TCPDump den Rahmen. Da es mit einem grafischen Interface in der Konsole daher kommt, ist es extrem leicht zu bedienen.
Daher einfach installiere und ausprobieren.
Durchsatzstatistik mit : ifstat
Wer nur eine kleine Statistik braucht, der kann einfach ifstat fragen :
Auch mit vnstat kann man Statistiken zu seinem Interface abrufen. Allerdings müssen die erst gesammelt werden, was bedeutet, daß man zwei Aufrüfe benutzen muß:
Dafür ist das keine Momentaufnahme, sondern ein wohl definierter Zeitraum. Damit lassen sich also Feststellungen machen, wieviel Traffic eine Anwendung verursacht hat. Natürlich nur, wenn nichts anderes stört.
Womit wir beim Schluß des Artikels wären und der Frage, ob da noch mehr existiert ?
Ja, das tut es. Will man z.b. sein Heimatnetzwerk verlassen, muß man dem Rechner gesagt haben, welcher andere Computer dem eigenen PC die Pakete abnehmen soll, um sie ins Internet weiter zu leiten. Dies geschieht über die Route, welche man mit dem Befehl route sehen und manipulieren kann. Da die meisten von Euch nicht in der Konsole arbeiten werden, sondern dem Gnome/Cinnamon im Netzwerkmanager gesagt haben, was er tun soll, schauen wir uns nur schnell die Ausgabe an und verzichten heute auf die Manipulation:
# route -n
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.121.1 0.0.0.0 UG 100 0 0 enp2s0
192.168.121.0 0.0.0.0 255.255.0.0 U 100 0 0 enp2s0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
Was man sieht sind alle verfügabren Netze und das ist ein Netz mehr als wir erwarten würden. Das Netzwerk 192.168.122.0, was man aufgrund der Netzmaske als ein Class-C Netz /24 identifizieren kann, wird von der Virtualisierung benutzt. Das wären z.B. VirtualBox oder das schon bei Fedora vorhandene Boxen Tool.
Das andere 192.168.121.0 Netzwerk, ist das normale LAN Netz (meines PCs) Bei Euch wird das anders aussehen.
Das Ziel 0.0.0.0 ist „Der Rest der Welt“ und wird vom Rechner mit der IP 192.168.121.1 „geroutet“. Den nennt man deswegen auch Gateway, nämlich Gateway in ein anderes Netzwerk. Man kann in einem LAN mehrere Gateways haben, man muß als nur in dieser Routentabelle dafür sorgen, daß jedes Zielnetzwerk mit seinem Gateway eingetragen ist. Dazu gehört auch, daß das Gateway mit einem Bein (und korrekter IP und Netzwerkmaske ) in eigenen LAN steht.
Damit soll es für heute genug sein.
Update um 9:09 Uhr :
Auch dieser Beitrag wurde von WordPress entgegen des Planungstermins, nicht angezeigt.
In einem Interview mit dem Guardian aus Großbritannien, hat Dr. Richard Stallmann, für ein anonymes Bezahlsystem geworben, das unter der Leitung von GNU entstehen soll. Statt Ihre Kunden zu Überwachen und mit Werbepopups zu nerven, sollten die Zeitungsverleger, denn um die geht es im Artikel, ihre Kunden einfach anonym bezahlen lassen, wenn sie einen Artikel lesen möchten.
Das gewünschte System heißt GNU Taler.{komplett falsche Infos wurden entfernt}
Dr. Stallmann geht soweit, daß das Bezahlsystem wirklich so anonym ist, daß man als Verleger auch nicht tracken könnte, wer welchen Artikel gelesen hat. Bleibt nur die Frage, wer wacht über diesen PayAnbieter ?
Das Bundeswirtschaftsministerium fördert über prototypefund.de mit 1,2 Millionen Euro Open Source Software, was das Bundesministerium für Verkehr und digitale Infrastruktur veranlaßte mal wieder die digitalen Neulandgeräte, sprich Smartphones, zu fördern:
Am Ende soll Open Source Software dabei rauskommen, die bei GitHUB u.ä. hinterlegt sein muß. Da hätte man auch gleich „Freie Software“ fordern können, hätte man den Unterschied dazu gewußt. „Förderungswürdig“ wird beim MFUND übrigens so angegeben:
„Mit dem mFUND unterstützt das BMVI die Entwicklung digitaler Geschäftsideen, die auf Mobilitäts-, Geo- und Wetterdaten basieren. Dazu zählen z.B. neue Navigationsdienste, innovative Sharing-Plattformen, intelligente Reiseplaner oder hochpräzise Wetter-Apps.“
Wir haben Livewetterkarten mit Livefeed vom Satelliten, wozu brauchen wir noch mehr unnütze Wetterapps, die sich zudem alle widersprechen ? Das Wetter ist, wie es ist, da wo man halt grade ist. Verlassen kann man sich auf keine Wetterkarte, auch nicht bei Kachelmann oder dem hauseigenen Wetterfrosch. Nicht einmal aufs Wetter kann man sich verlassen, wie ein Test neulich bei einer Geburtstagsfeier im Freien ausdrücklich gezeigt hat: Eine Gewitterfront, die zielstrebig auf uns zu kam, meinte dann doch, daß die 70 km bis zu uns, für welche die Front knapp eine Stunde gebraucht hätte, den ganzen Aufwand nicht wert war und schwenkte dann einfach richtig England um. Dort wird sich die Schlechtwetterfront dann am Ende auch viel wohler gefühlt haben, mit all den anderen Schlechtwetterwolken, die üblicherweise in London ihr EU Hauptquartier haben.
Aber zurück zum mFUND: Wieviel Navigationsdienste glaubt man im BMVI eigentlich, braucht ein Autofahrer ? Könnte es sein, daß die Strecke freier wird, wenn alle anderen mit einer anderen App im Stau stehen ? Oder nehmen wir Filesharing, wie oft soll ich die eine Datei noch teilen ? Vor lauter Teilenbuttons kann man einige Webseiten schon gar nicht mehr als mit Inhalt versehen erkennen! Sollen wir jetzt auch noch eine Sharingapp bauen, welche die geteile Datei auf dem Handy des Freundes dann sofort/wahlweise/nie/irgendwann/nächsten Dienstag löscht ? also Snapfile erfinden ? Oder war hier vielmehr gemeint, daß man sich selbst shared, damit die ganzen Apps was zutun haben ?
Fest steht, daß hier Geld zum Fenster hinausgeworfen wird, um Projekte zu finanzieren, die ohnehin keine Chance haben, weil die amerikanischen Startups die Idee schneller aufnehmen und umsetzen können, als deutsche Beamte den Förderantrag bearbeiten werden. Vergeßt es einfach, Eure Idee ist schon weg, bevor das erste Geld kommt !
Hat sich mal jemand die Frage gestellt, was mit der Volkwirtschaft passiert, wenn statt einer app, hunderte apps den gleichen Job machen? Nein, dann beantworte ich das mal: Einem Rudel von Investoren wird Geld dafür abgenommen, eine Reinkarnation eines bereits erfolgreichen Unternehmens zu bauen. Sollte es dem neuen Nachbau gelingen signifikante Anteile am Markt zu erobern, könnte die Strategie aufgehen und die neue Firma wird von der Alten aufgekauft. Wenn jetzt aber hundert neue Unternehmen die wenigen Marktanteile unter sich aufteilen, führt das zu einer Menge verlorenem Kapital und einer Reihe arbeitsloser Programmierer, weil die paar Kunden dem Marktführer egal sind und er die Firmen nicht aufkauft.
Volkswirtschaftlich betrachtet, ist das deswegen Schwachsinn, weil es am Ende nur Verlierer gibt. Die Firmen, die den neuen Firmen die Webservices zur Verfügung gestellt haben, müssen ihrerseits den wegbrechenden Kundenstamm kompensieren und werfen die eigens eingestellten Leute auch wieder raus. Die Kapitalgeber verlieren sowieso alles und die Entwickler in den neuen, aber alsbald liquidierten Firmen, wurden davon abgehalten mit Ihrer kostbaren Zeit etwas neues zu erschaffen, das im Gegensatz zur Reinkarnation sinnvoll ist und auf Dauer bestehen bleibt. Vielleicht die Vermieter der Lofts der kurzeitig reichen Startupgründer finden das toll, weil sie so die Mietpreisbremsen umgehen können, denn gewerbliche Vermietungen fallen ja ja nicht drunter.
Liebes BMVI, fördert doch mal etwas, was wir wirklich dringend brauchen:
oder am besten überhaupt mal die Pflicht der Anbieter für Ihr Produkt 2 Jahre nach Verkaufsdatum noch Updates anzubieten. Dafür könnte man ja mal Kohle rauswerfen. In dem Sinne, einen schönen Wochenstart.
