Kategori Netzwerk

Alle Amazon Web Service EC2 Instanzen rebooten

Freitag, Januar 13th, 2012

Heute musste ich mal alle AWS Instanzen neustarten. Dafür habe ich alle Aktiven Instanzen heraus gegept und in eine TMP Datei geschrieben. Diese habe ich dann zum neustarten der Server verwendet.
[UPDATE] Das gilt natürlich nur dann wenn man auch seien SSH-KEY hinterlegt hat. [/UPDATE]

#!/bin/bash
export EC2_PRIVATE_KEY=$(pwd)/pk-xxx.pem
export EC2_CERT=$(pwd)/cert-xxx.pem
tmp=$(mktemp)

ec2-describe-instances | grep INSTANCE | awk '{print $4}' > $tmp

while read server; do 
        echo "${server}" 
	ssh "${server}" "reboot" 1>/dev/null < /dev/null &
	sleep .1
done < $tmp

rm $tmp
exit 0

Tinc Debugging

Donnerstag, Januar 5th, 2012

Um Tinc besser Debuggen zu können kann man das syslog einfach in den Hintergrund schreiben und mittels killall -USR2 tincd anstupsen. Das sieht dann folgender massen aus.

tail -F /var/log/syslog &
...
killall -USR2 tincd
srv01 tinc.vpn[28369]: Statistics for Linux tun/tap device (tun mode) /dev/net/tun:
srv01 tinc.vpn[28369]: total bytes in: 294
srv01 tinc.vpn[28369]: total bytes out: 294
srv01 tinc.vpn[28369]: Nodes:
srv01 tinc.vpn[28369]: srv02 at 1.2.3.4 port 655 cipher 91 digest 64 maclength 4 compression 0 options d status 003a nexthop srv01 via srv01 pmtu 1451 (min 1451 max 1451)
srv01 tinc.vpn[28369]: End of nodes.
srv01 tinc.vpn[28369]: Edges:
srv01 tinc.vpn[28369]: srv02 to srv01 at 1.2.3.4 port 655 options d weight 328
srv01 tinc.vpn[28369]: srv01 to srv02 at 1.2.3.5 port 655 options d weight 328
srv01 tinc.vpn[28369]: End of edges.
srv01 tinc.vpn[28369]: Subnet list:
srv01 tinc.vpn[28369]: 192.168.0.0/24#10 owner srv01
srv01 tinc.vpn[28369]: End of subnet list.

Mit fg und STRG + C kann man das teil -F wieder aus dem Hintergrund holen und beenden.

Tinc und GIT

Sonntag, Januar 1st, 2012

Tinc ist im Gegensatz zu OpenVPN eine mesh vpn. Damit dies funktioniert müssen aber auf jedem Server die öffentlichen Schüssel/Konfigurationsdateien bekannt sein. Um diese Schlüssel zu verteilen verwende ich GIT.

Hier ein Aufbau zwischen zwei Servern (SRV01/SRV02). Jeweils habe den Ordner /opt/git/ erstellt und das Git ausgeschekt. Den VPN Ordner habe ich dann mittels eines Symlinks in das /etc/tinc Verzeichnis gelinkt.
ln -s /opt/git/vpn.tinc/vpn /etc/tinc/vpn

Folgende Daten und Ordner befinden sich in meinem Git. Mittels der .d Verzeichnisse werden die einzelne Dateien auf den Servern gelinkt (siehe unten).
/etc/tinc/vpn/
hosts
hosts/srv01
hosts/srv02
tinc.conf.d
tinc.conf.d/srv01.conf
tinc.conf.d/srv02.conf
up.d
up.d/srv01-up
up.d/srv02-up
down.d
down.d/down

Die Dateien im einzelnen.
— SRV01 —
hosts/srv01:

Name = srv01
Address = srv01.chr.istoph.de
Cipher = aes-256-cbc
Digest = sha1
IndirectData = yes
Subnet = 10.8.0.1/32
Subnet = 192.168.0.1/24

Wichtig: bei Subnet muss einmal die Lokale Adresse auf die gelauscht werden soll mit /32 angegeben werden. Das zweite Subnet ist nur beispielhaft für weiteres netz das sich hinter SRV01 befindet.

tinc.conf.d/srv01.conf:

Name = srv01
AddressFamily = ipv4
BindToInterface = eth0
ConnectTo = srv02
Device = /dev/net/tun
Mode = router
KeyExpire = 3600
PrivateKeyFile = /etc/tinc/vpn/rsa_key.priv

up.d/srv01-up:

#!/bin/bash
ip addr add 10.8.0.1/24 dev vpn
ip link set vpn up

down.d/down:

#!/bin/bash

Auf SRV01 müssen dann natürlich nur folgende Symlinks erstellt werden.
ln -s tinc.conf.d/srv01.conf tinc.conf
ln -s up.d/srv01-up tinc-up
ln -s down.d/down tinc-down

— SRV02 —
hosts/srv02:

Name = srv02
Address = srv02.chr.istoph.de
Cipher = aes-256-cbc
Digest = sha1
IndirectData = yes
Subnet = 10.8.0.2/32

tinc.conf.d/srv02.conf:

Name = srv02
AddressFamily = ipv4
BindToInterface = eth0
ConnectTo = srv01
Device = /dev/net/tun
Mode = router
KeyExpire = 3600
PrivateKeyFile = /etc/tinc/vpn/rsa_key.priv

up.d/srv02-up:

#!/bin/bash
ip addr add 10.8.0.2/24 dev $INTERFACE
ip link set $INTERFACE up

ln -s tinc.conf.d/srv02.conf tinc.conf
ln -s up.d/srv02-up tinc-up
ln -s down.d/down tinc-down

— END —

Nach dem die Dateien angelegt sind können auf dem jeweiligen Server (SRV01 / SEV02), die Keys erstellt werden.
tincd --generate-keys=4096 -n vpn

Dies Legt den Privaten schlüssel rsa_key.priv an und legt den Öffentlichen Schlüssel in die host/srv01 Datei.

Vor dem Starten von Tinc müssen die up/down Scripte noch Ausführungsrechte auf den Jeweiligen Servern bekommen.
chmod +x up.d/srv*
chmod +x down.d/down

Nun können wir alles im GIT einchecken. Nicht vergessen nach dem einchecken von SRV01 auf SRV02 zu pullen und erst dann die Dateien anzulegen um sie zu puschen.
git add hosts/srv01 tinc.conf.d/srv01.conf up.d/srv01-up down.d/down
git commit -m "tinc: add srv01"
git puch

Wichtig hierbei ist den Privaten Schlüssel rsa_key.priv nicht einzucken. Auch aus Backup gründen macht dies keinen Sinn da dieser immer wieder neu erstellt werden kann.

Bei Ubuntu 14.04 Systemen muss in der Datei /etc/tinc/nets.boot der Name des zu startenden Netzwerkes eingetragen werden. In unserem Fall VPN.
## This file contains all names of the networks to be started on system startup.
vpn

Ab Ubuntu 16.04. können die einen Tinc Netzte via Systemd angesprochen werden. In Unserem Fall damit es bei Boote gestartet wird:
systemctl enable tinc@vpn
Und folgendes zum Starten und Status anzeigen:
systemctl start tinc@vpn
systemctl status tinc@vpn

AWS Amazon Web Service EC2 Scripten

Dienstag, Dezember 20th, 2011

Für einen Lasttest habe ich etliche AWS Micro Instanzen mit Ubuntu 10.4 benötigt, die alle vorkonfiguriert werden mussten. Da man aber nicht Tausend Instanzen von Hand Einrichten und Konfigurieren will musste mal wieder ein Script her.

Als erstes braucht man die ec2-api-tools
sudo apt-get install ec2-api-tools

Dann habe ich ein Start Script Namens run-file.sh geschrieben, das z.b. so aussieht:
#!/bin/bash

apt-get update
apt-get install -y apache2-utils
ab http://blog.chr.istoph.de/

Dann habe ich die Instanzen mittels eine for Schleife gestartet.
for i in {1..1000}; do
ec2-run-instances ami-e52ce68c --instance-type t1.micro --region us-east-1 --key ca -K pk-xxx.pem -C cert-xxx.pem -user-data-file run-file.sh
done

Das starten der Instanzen sollte nicht mittels & in den Hintergrund geschoben werden, da das Programm ec2-run-instances ein sehr Speicherfressendes Java Programm ist.

Nachdem man jetzt die 1000 Instanzen eine Weile laufen gelassen hat muss man diese auch wieder beenden. Dazu kann man sich folgendermaßen alle Instanzen anzeigen:
ec2-describe-instances -K pk-xxx.pem -C cert-xxx.pem

Dem endsprechen kann man auch ALLE existierende Instanzen gelöscht werden:
ec2-terminate-instances -K pk-xxx.pem -C cert-xxx.pem $(ec2-describe-instances -K pk-xxx.pem -C cert-xxx.pem | grep INSTANCE | awk '{print $2}')

Quelle: help.ubuntu.com
uec-images.ubuntu.com

OpenSSH Fingerprinte im DNS

Sonntag, November 27th, 2011

Jetzt habe ich endlich mal eine einfache Anleitung gefunden um OpenSSH Fingerprinte im DNS zu hinterlegen (RFC4255).

Denn ssh-keygen kann diereckt den für BIND nötigen SSHFP record erstellen.

root@ns01:~# ssh-keygen -r ns01.caix.de -f /etc/ssh/ssh_host_rsa_key.pub
ns01.caix.de IN SSHFP 1 1 e208441777cba0459c52e8680b617b254183f711
root@ns01:~# ssh-keygen -r ns01.caix.de -f /etc/ssh/ssh_host_dsa_key.pub
ns01.caix.de IN SSHFP 2 1 0476a2a57fb720fbee586b78e28490929501d8c6

Nach dem veröffentlichen im DNS kann mal den Record mit dig abrufe.
dig -t SSHFP ns01.caix.de

;; ANSWER SECTION:
ns01.caix.de. 7200 IN SSHFP 1 1 E208441777CBA0459C52E8680B617B254183F711
ns01.caix.de. 7200 IN SSHFP 2 1 0476A2A57FB720FBEE586B78E28490929501D8C6

Testen kann mal das ganze dann mit der Option VerifyHostKeyDNS und -v für den Debug mode. Die zwei entscheiden Zielen habe ich unten aufgeführt.

ssh root@ns01.caix.de -o VerifyHostKeyDNS=yes -v
...
debug1: found 2 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
...

Quelle: bd.hauke-lampe.de