RDP unter Gnome

Als [[Telearbeit|Telearbeiter]] benutze ich RDP Tag für Tag. Bisher habe ich immer den TSClient unter Gnome verwendet. Aber leider unterstützt TSClient nicht die Freigabe von lokalen Drucker an den Remote Server. Es existiert zwar ein entsprechender Patch aber das Projekt scheint eingeschlafen zu sein, so dass der Patch noch nicht integriert wurde. Deswegen habe ich heute mal eine Alternative gesucht. Mit grdc habe ich endlich eine wirkliche Alternative gefunden. Das Teil gefällt mir gut. Das wichtigste ist, dass es pro pro Host auch die Möglichkeit bietet weitere Parameter an rdesktop mit zu geben. So kann ich mit -r printer:HL2040 meinen lokalen Drucker freigeben und auch die serielle Schnittstelle weiterreichen. Sehr gut! Achja, das Teil kann auch VNC.

iproute2 – source based routing

Source based routing ist nicht schön, aber manchmal wirklich notwendig. Allerdings geht es mit dem iproute2 Paket auch wirklich einfach. In meinem Fall habe ich 2 Internet-Anbindungen wovon die erste (default) für alle offziellen Adressen genutzt werden soll, die zweite rein für Traffic aus dem VPN.

Folgende Schritte sind notwendig.

  1. Als erstes muss die Tabelle in /etc/iproute2/rt_table definiert werden. In meinem Fall:
    10 vpn-link
    
  2. Das Routing für das VPN muss definiert werden:
    ip route add 172.16.128.0/20 via 172.16.1.253 table vpn-link
    ip route add default via 172.16.1.254 table vpn-link 
    ip route list table vpn-link 
  3. Jetzt muss noch die Tabelle für die Source Route aktiviert werden
    ip rule add from 172.16.128.0/20 table vpn-link
    ip rule list
    

Ginge das nur mit Windows auch so einfach.

Source based routing ist übrigens nicht schön, weil es mehr Last erzeugt. Schließlich müssen weitere 32 Bit (Source-Adresse) aus dem IP-Header verarbeitet werden.

nutzloses hotssh

Gestern hatte ich endlich Zeit mein Notebook mal wieder auf den aktuellen Stand zu bringen. Ich hab Ubunutu auf 9.04 gebracht. Seither ist hotssh nutzlos. Egal welchen User ich für eine aktuelle Verbindung nutze hotssh versucht wieder und wieder sich mit meinem aktuellen User anzumelden. Nachdem die meisten meiner Kisten per fail2ban „gesichert“ sind werde ich nach kürzester Zeit ausgesperrt. Schade! Das Tool wäre wirklich so praktisch.

Den Bug habe ich mal bei Ubuntu eigekippt, denn Otto hat das gleiche Problem und hat schon beim Entwickler selbst einen angelegt. Hier der Link zu meinem Bug Report. Hoffentlich wird der resolved.

Kennt jemand eine Alternative zu hotssh?

SSH Root Zugang – aber sicher

Auf vielen Maschinen verbiete ich den SSH Zugang per Root per default indem ich in der sshd_config folgendes eintrage:

PermitRootLogin no

Damit muss sich jeder erst einmal persönlich anmelden und kann dann lokal root werden. So ist sauber dokumentiert, wer sich angemeldet hat.

Manchmal geht das aber nicht. Es gibt Fälle, wo der root User von anderen Sachen benutzt wird (z.B. Backup-Software). Ist zwar nicht schön, aber wenn es sein muss. Dann muss ich aber auch jedes mal wieder nachlesen, wie ich den Root-Zugang auf Zertifikate beschränke. Daher hier die Notiz. So geht’s:

PermitRootLogin without-password 

Das ganze ist natürlich nur so sicher, wie der private Schlüssel des öffentlichen Schlüssels, der beim Root-User hinterlegt ist.

OpenVPN – mein Retter in der Not

Ich konnte es nicht glauben. Es gibt tatsächlich noch Flecken in Deutschland, die keinen Handyempfang haben. Ich laufe ja immer mit 2 UMTS Karten herum und zwar Vodafone und T-Mobile. Beide Karten waren an dem Ort, wo ich am Samstag war nutzlos. An Internet per UMTS war nicht zu denken. Ich musste aber irgendwie ins Netz. Gott sei Dank hatte die Stadtverwaltung ein Ethernet-Kabel für mich. Natürlich war aber da nur HTTP und HTTPS erlaubt. Zudem ging alles über einen Proxy. Nachdem ich auf andere Ports angewiesen war, bin ich erstmal ganz schön dumm da gestanden. Zum Glück hatte ich ein OpenVPN Gateway im Rechenzentrum. Zusammen mit der Option –redirect-gateway war ich ohne Einschränkungen im Internet. Mein Tag war gerettet.

Redundante DNS Server – Teil 2

Die ersten Antworten auf den letzten Artikel sind schon da. Interessant ist, dass manche Leser der Meinung sind sie hätten solche Probleme nicht. Sie verwenden die DNS-Server ja nur intern. Und tragen brav alle verfügbaren in der resolv.conf Datei ein. Für diese Leser ist dieser 2te Artikel gedacht.

Nun im Gegensatz zum Zonenfile spielt die Reihenfolge in der Konfigurationsdatei eine Rolle! Ich zitiere mal die wichtigsten Stellen aus der manpage von resolv.conf:

(…) If there are multiple servers, the resolver library queries them in the order listed. (…) The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made. (…)

Die wichtigsten Default Werte sind folgende:

  • MAXNS = 3
  • timeout = 5
  • attempts = 2

Somit ist klar, fällt der ersten Nameserver in der Liste aus, dauert jeder Query mindestens 5 (!!) Sekunden um von den zweiten die entsprechende Antwort zu bekommen. Und mehr wie 3 Nameserver (MAXNS) bringt sowieso nichts. Also selbst wenn man Nameserver „nur“ intern verwendet müssen diese möglichst hochverfügbar sein. „Viel (Nameserver) hilft viel“ gilt hier nicht.

Redundante DNS Server

Über das Verhalten von DNS Queries diskutiere ich sehr gerne. DNS Abfragen funktionieren anders als die meisten sich das vorstellen. Hat eine Zone mehrere NS Records (etwa ns1.provider.de und ns2.provider.de) wird nicht immer der erste genommen und erst dann auf den zweiten geschwenkt, wenn der erste nicht mehr erreichbar ist. DNS funktioniert anders! Hat ein Nameserver die Zone für eine bestimmte Domain nicht geladen, so wird erst der schnellste Nameserver aus den angebotenen ermittelt. Dieser wird dann immer benutzt. Fällt er mal aus, so erhält der Nameserver eine Strafe und fällt in der Rangliste nach hinten. Läuft er schon länger braucht es aber einige Zeit bis er hinter den zweiten zurückfällt (das kann Stunden dauern). Damit sind die DNS Anfragen beim Ausfall des schnellsten plötzlich sehr sehr langsam und der darüber erreichbare Service kann den Anschein haben er sei ausgefallen. Das dümmste ist also einen der DNS Server (also auch den sekundären) nicht redundant auszustatten. Man weiß ja nie sicher wo die Anfragen landen. Verlangsamt man die Anfragen auf dem „sekundären“ künstlich, damit er immer der sekundäre bleibt, bekommt er zwar normalerweise wenig Anfragen, das Umschalten dauert im Ausfall des ersten dennoch ewig. => Sinnlos

Aber wozu dann überhaupt mehrere NS Einträge / Server?

Ganz einfach! Nachdem immer der schnellste genommen wird, ist es meist auch der nächste Nameserver im Netz. In dem man die verschiedenen Nameserver geschickt platziert verringert man sowohl Antwortzeiten als auch Traffic. Das ist auch der Grund warum etwa Denic Nameserver auf der ganzen Welt platziert, oder warum es nicht nur einen Root-Server gibt.

Immer wenn ich mal Zeit habe versuche ich die Links zu finden, die das Verhalten dokumentieren. Jetzt merke ich mir mal die ersten Links hier:

  • Windows (siehe: Note: If multiple NS records exist for a delegated zone identifying multiple DNS servers available for querying…)
  • Bind

Fortsetzung folgt.

GPS Time != UTC

Dass die Zeit per UTC nicht identisch zur Zeit per GPS ist, glaubt fast keiner. Endlich habe ich bei der US-Navy den entsprechenden Link mit Hintergrund Infos gefunden. Wenn mal wieder jemand daran zweifelt, muss ich nur noch auf diesen Blog-Artikel verweisen. Angeblich sollen sich ja die Endgeräte um diese genau definierte Abweichung kümmern. Ich glaube nicht, dass das immer zu 100% funktioniert. Genauso habe ich meine Zweifel, dass die gängige GPS Software die Verzögerung beim Auslesen der Geräte z.B. per seriellen Interface berücksichtigt.

Aber was soll’s Zeit ist doch sowieso relativ 😉

Postfix: SMTPs Auth (ausgehend)

Ich bin nicht nur die EDV-Abteilung im Laden meines Bruders, nein auch meine Kisten sind die Internet-Server für Ihn. D.h. auch Mails werden über mich geschleußt. Zum Versenden sollen Sie sich mit meinem Server sicher verbinden. Das setzt 2 Sachen voraus: 1. SMTPs und 2. Authentifizierung. Das erst geht mit Postfix problemlos. Fürs zweite mißbrauchen ich stunne. Ich schreib mir hier mal die Anleitung auf:

  1. SMTP Auth
    etc/postfix/main.cf

    relayhost = localhost:1025
    smtp_sasl_auth_enable = yes
    smtp_sasl_security_options = noanonymous
    smtp_use_tls = no
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    

    /etc/postfix/sasl_passwd

    localhost ACCOUNT:PASSWORD
    

    Wichtig hierbei ist, dass der Relayhost localhost und der Port 1025 ist. Darüber wird im Schritt 2 die SMTPs Verbindung zu meinem Server hergestellt.

  2. SMTPs
    client = yes
    foreground = no
    [smtps]
    accept = 1025
    connect = mail.it4sport.de:smtps
    

    stunnel muss über ein einsprechendes Startskript gestartet werden.

Ziemlich einfach und sicher.