chr.istoph, der Blog

Meine Support anfrage:

Nach dem Neuaufsätzen des Servers ist das von Ihnen Konfigurierte IPv6 Netz ist nicht
funktionsfähig:

Von Intern:
1. ex3k14.rz14.hetzner.de 0.0% 3 4.5 2.2 1.0 4.5 1.9
2. ???

Von Extern:
1. 2a00:fe0:2::1 0.0% 42 0.5 0.8 0.4 10.9 1.6
2. bb2-ks.as34953.net 0.0% 42 21.2 22.2 20.9 29.7 1.6
3. 2a00:fe0:0:8::2 0.0% 42 27.2 27.6 26.6 29.8 0.6
4. decix-gw.hetzner.de 0.0% 42 29.1 29.1 28.1 37.3 1.4
5. core1.hetzner.de 0.0% 42 29.7 28.9 27.8 30.5 0.6
6. core22.hetzner.de 0.0% 41 34.4 33.5 32.6 34.4 0.5
7. juniper2.rz11.hetzner.de 0.0% 41 34.2 34.2 32.3 46.4 2.1
8. ???

Antwort Support:

Sehr geehrte Damen und Herren,

haben Sie schon einmal geprüft ob das Problem auch im Rescue-System besteht? Damit
könnten wir einen Fehler in der Konfiguration ausschließen.

Was für eine Blöde Antwort, das System ist gerade frich aufgesetzt. Zudem erreiche ich mein Gateway danach geht es erst nicht weiter. Meine Vermutung hier war das es sich um den gleich Fehler handelt wie: ipv6-probleme-bei-hetzner

Meine Antwort:

Ja, das Problem ist im Rescue-System reproduzierbar!

Antwort Support:

Sehr geehrter Herr Hueffelmann,

wir würden das Ticket zur Bearbeitung gerne an unsere Netzwerkabteilung
weiterleiten, diese ist jedoch nur von 8 – 16 Uhr erreichbar. Wenn Sie dies
dennoch wünschen dann schreiben Sie uns bitte einfach erneut.

„Dennoch“?

Morgens um 09:00

Das Problem besteht weiter hin, bitte leiten sie das Ticket jetzt an
die Netzwerk abteilung weiter.

Antwort Support:

Sehr geehrter Herr Hueffelmann,

Ihr IPv6-Subnet ist dem falschen Rechenzentrum zugeordnet und kann daher nicht im
RZ 14 genutzt werden. Wir haben das Netz entsprechend gekündigt und Sie können
über den Robot ein neues bestellen.

Ein neues Netz hätte man mir auch gestern Abend zusenden können. Quasi nach der erste anfrage.

OpenVPN nutzt zur Bestimmung der Maximum Transmission Unit (MTU) ICMP Pakete des Typs 3. Dafür ist es dringend erforderlich das man diese auch an der Firewall zulässt.

If a software or hardware firewall is in place (especially if the firewall is whitelisting connections), make sure it is allowing ICMP Destination Unreachable: Fragmentation Needed (ICMP Type 3, Code 4) into your network. Windows Firewall, by default, has this rule configured, and there is no need to add this rule explicitly on Windows machines.
Quelle: docs.openvpn.net

Wenn man sich das auf dem VPN Server anschaut sieht das so aus:

tcpdump -i eth0 -p icmp
11:01:01.298080 IP 1.1.1.1 > vpn.chr.istoph.de: ICMP 1.1.1.1 unreachable - need to frag (mtu 1418), length 36
11:01:01.298084 IP 1.1.1.1 > vpn.chr.istoph.de: ICMP 1.1.1.1 unreachable - need to frag (mtu 1418), length 36

Als Empfehlung gebe ich mit mindestens die folgende Pakete freizuschalten.

iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT -m comment --comment "ICMP  Echo Reply"
iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT -m comment --comment "ICMP  Destination Unreachable"
iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT -m comment --comment "ICMP  Echo Request"
iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT -m comment --comment "ICMP  Time Exceeded"

Frage:

Ich habe durch Google Ihre Webseite gefunden, da ich Informationen brauchte. Und da dachte ich mir, vielleicht können sie mir Weiterhelfen.

z.Z benutze ich einen NAS Speicher zyxel-nsa-220
bin damit aber gar nicht mehr zufrieden.
Also dachte ich mir, mach ich doch nen Debian 7 Server und baue die Platte da rein. Leider laufen die Platten als JBOD soweit ich das gelesen habe ist das Kein RAID. Aber auf dem NAS ist es wohl mit „mdadm“ Konfiguriert und da dachte ich das muss auch unter Debian laufen.

Jetzt ist meine frage, ist es möglich die Platten wieder zu Mounten oder geht das gar nicht und ich müsste von den 2×1 TB Platten erst einmal ein
Backup machen ?

P.s: ich hoffe ich belästige sie nicht damit.

LG
Marco

Antwort:

Hallo Marco,
mit Freuden habe ich deine E-Mail erhalten und gebe Privat läuteten gerne Auskunft. Für alle Business Kunden verweise ich hier mal auf meinen Beratervertrag 😉
Zu erst mal ist deine Vermutung das JBOD kein Raid ist, völlig richtig. Die Übersetzung davon ist „Just a Bunch of Disks“, also: Nur ein Haufen Festplatten. Qeulle wikipedia.org

Das Problem was du hast ist das dein Kernel/initrd vor /dev/sda booten wird und nicht von einem MD Device wie /dev/md0. Um das umzustellen habe ich folgende einfachen Ansatz.
Du machst eine Neuinstallation auf der zweiten Platte und gibst bei der Installation, während der Partitionierung an, das du ein RAID erstellen möchtest lässt aber deine aktuelle Systemplatte aus (Spare). Nach der Installation kannst du deine Daten von der dann alten Systemplatte auf die neu installierte Platte kopieren und anschließend die Platte ins RAID mit aufnehmen. Dafür empfehle ich dir den MBR mittels sfdisk zu kopieren.
sfdisk -d /dev/sdX > /dev/sdY
Quelle: Partitionstabelle-sichern
Dann kannst du die Platte, nach einem Reboot, mittels mdadm --add /dev/md0 /dev/sdX1 in den Verbund mit aufnehmen.

Grundsätzlich geht das auch ohne Neuinstallation ist aber nicht ganz trivial.

Gruß Christoph

Hatte ich doch ursprünglich eigentlich nur vor auf meinem neuen Snom 870 (ein IP-Telefon) einfach einen VPN-Router nach der Anleitung im SNOM-Wiki (wiki.snom.com) aufzusetzen.
Da die Anleitung ziemlich unverständlich ist, dauerte es erstmal bis das ich überhaupt Skripte mit dem VPN ausführen konnte.

1.  Man muss in der OpenVPN-Config die Script-Security auf 3 system setzen. (Danke an den Blog-Inhaber)
   script-security 3 system
2. Man sollte unbedingt im SNOM einen NC-Listening-Server angeben um die Logs vom OpenVPN-Deamon lesen zu können.
3. Man erwate nicht, dass das Script aus dem Snom-Wiki funktioniert. Nach einigen Versuchen klappte es dann. Mein Skript sah aber nun so aus.
4. while true ; do nc -l -p 8080 -c /bin/bash ; done

Mit einer primitiven Shell (ohne stderr und ohne Readline) ließ es sich herausfinden, dass auf dem SNOM 870 ein SSH-Server installiert ist. Es fehlten allerdings die Host-Keys. Zwar lassen sich die theoretisch auch auf dem SNOM anlegen, aber ich würde empfehlen diese auf einem anderen Computer anzulegen und über einen USB-Stick auf das Gerät zu schieben und unter /etc/ssh abzulegen.
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key

Ein 16 GB vFAT formatierter USB-Stick ließ sich problemlos mounten.
Zum starten des ssh-servers genügt es dann einfach

/usr/bin/sshd

zu starten.
Da ich mir unsicher war, was passiert, wenn ich root ein Passwort gebe, habe ich kurzer Hand meinen SSH-Public-Key per

ssh-copy-id root@snom870

auf das Gerät geschoben.

Ein anschließendes Umsehen auf dem Gerät war sehr ernüchternd: Weder die Switch-Config

/proc/driver/switch_api

noch iptables waren auf dem Gerät.

Ein

cat /proc/cpuinfo


verriert mir aber, dass es sich um eine ARM-CPU handelt, wie sie auch in vielen Android-Smartphone zu finden ist.
Die meisten Android-System-Binarys (also keine APK-Dateien) lassen sich auf dem Gerät ausführen.

EDIT:
Um auf das Snom zu kommen ruft man einfach nc ip_snom870 8080 auf. Telnet eignet sich dafür nicht so sehr.
Zum Automatischen starten des sshd kann man einfach in der /etc/init.d/rcS, die Funktion startUpDaemons um folgende Zeilen ergänzen:

display "Start sshd" ".."
/usr/sbin/sshd


Mit verschiedenen Werkzeugen ist es möglich über die in RFC 1323 Section 3.2 Spezifizierte Option die Uptime eines Rechners zu ermitteln. Der Theorie nach soll man so Angriffe gegen ungepachte Kernel / Sicherheitsupdates fahren können.
Hier ein nmap Beispiel:

sudo nmap -O -v 10.0.0.1

Starting Nmap 6.25 ( http://nmap.org ) at 2013-10-17 22:21 CEST
Initiating ARP Ping Scan at 22:21
Scanning 10.0.0.1 [1 port]
Completed ARP Ping Scan at 22:21, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 22:21
Completed Parallel DNS resolution of 1 host. at 22:21, 0.05s elapsed
Initiating SYN Stealth Scan at 22:21
Scanning 10.0.0.1 [1000 ports]
Discovered open port 22/tcp on 10.0.0.1
Completed SYN Stealth Scan at 22:21, 0.17s elapsed (1000 total ports)
Initiating OS detection (try #1) against 10.0.0.1
Nmap scan report for 10.0.0.1
Host is up (0.0011s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: B8:27:EB:00:00:00 (Raspberry Pi Foundation)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.6
Uptime guess: 17.048 days (since Mon Sep 30 21:12:28 2013)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=255 (Good luck!)
IP ID Sequence Generation: All zeros

Read data files from: /usr/local/bin/../share/nmap
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.00 seconds
           Raw packets sent: 1023 (45.806KB) | Rcvd: 1015 (41.282KB)

Die „Schätzung“ von nmap von 17.048 Tagen liegt mit der Tatsächlichen Uptime 17 days, 1:14 gut überein.

Um dies nun zu Unterbinden kann eine der beiden Möglichkeiten gewählt werden:
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
sysctl net.ipv4.tcp_timestamps=0

oder direkt in der /etc/sysctl.conf eingetragen werden:
net.ipv4.tcp_timestamps=0

Dann bekommt nmap keine sinnvollen antworten mehr:
(mehr …)