Manche Proxies kennen Möglichkeiten, um dieses Problem zu umgehen. SNIProxy lässt sich in einem transparenten Modus betreiben, in dem die Quell-Adresse der Verbindungen beibehalten wird.

SNIProxy im transparenten Modus

SNIProxy in den transparenten Modus zu versetzen ist auf den ersten Blick ganz einfach: Über die Konfigurationsdirektive source client im passenden Listener teilt man dem SNIProxy mit, er möchte doch bitte als Quell-Adresse für die Verbindungen gegen innen die ursprüngliche IP des Clients verwenden, z.B. so:

listen 192.168.1.15 80 {
   proto http
   source client
....

Als Beispiel verwenden wir 192.168.1.15 als IP für den Proxy. Es gibt dabei allerdings die eine oder andere Hürde zu umschiffen:

• Der transparente Modus funktioniert nur bei Listenern, die nur eine IP-Version verwenden. Es ist also notwendig, separate Listener für IPv4- und IPv6-Verbindungen einzurichten. In obigem Beispiel geben wir explizit die Adresse an, auf die der Listener hören soll, d.h. wir legen uns in diesem Beispiel auf IPv4 fest.
• Die Antwort-Pakete der Webserver, auf die SNIProxy weiterverbindet, müssen durch den Proxy-Rechner geroutet werden. Im einfachsten Fall wird dieser als Router aufgesetzt und die Webserver erhalten ihn als Default-Gateway.
• Auf dem Proxy-Rechner selbst muss per IPTables dafür gesorgt werden, dass die Pakete auch tatsächlich durch den transparenten Proxy laufen.
   

iptables und Policy Route auf dem Proxy-Rechner

Damit der Transparentmodus richtig funktioniert, müssen Pakete passend geleitet werden. Dies geschieht durch eine separate Routing-Tabelle, auf die Pakete per Markierung durch iptables geleitet werden:

iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT

ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

Auf dem Proxy-Rechner muss ausserdem Forwarding eingeschaltet sein, z.B. durch folgende Einträge in /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Webtraffic auf den Webservern durch den Proxy umleiten

Im einfachsten Fall wird ganz einfach die Default-Route der Webserver auf den Proxy gelegt. Das ist nicht immer praktikabel. Eine Variante davon ist, lediglich die Antworten des Webservers über den Proxy umzuleiten. Auch dies gelingt mit einer Policy-Route und einer iptables-Markierung, etwa so:

iptables -t mangle -A OUTPUT -p tcp --sport 443 -j MARK --set-mark 0x8
iptables -t mangle -A OUTPUT -p tcp --sport 80 -j MARK --set-mark 0x8

ip rule add fwmark 8 lookup 101
ip route add 192.168.1.15 dev eth0 table 101
ip route add default via 192.168.1.15 table 101

Auch hier gegen wir als Beispiel wieder vom auf der Adresse 192.168.1.15 laufenden Proxy aus und leiten alle ausgehenden Pakete mit Quellport 80 oder 443 auf diesen um.

Versuchen Sie einmal, ob es funktioniert, wenn Sie

• die Shift-Taste gedrückt halten
• mittels 

  :set mouse=r

  die Mausunterstützung ziemlich einschränken

Wenn im vim die Mausunterstützung eingeschaltet ist und das Terminal dies unterstützt, dann wird eine Selektion per Maus vom vim abgefangen. Typischerweise verwendet vim das *-Register (System-Clipboard), so dass eigentlich alles wie gewohnt funktioniert. In manchen Konstellationen funktioniert allerdings die Mausunterstützung im Terminal, aber nicht das System-Clipboard. Dann bleiben Selektionen nur innerhalb der gleichen vim-Instanz verfügbar, aber es ist nicht möglich, z.B. zwischen verschiedenen Fenstern zu Copy&Pasten.

Die Lösung besteht darin, die Mausunterstützung auszuschalten (dann wird auch wieder die Copy&Paste-Funktion des Systems aktiv) oder per Druck auf die Shift-Taste nur für gerade diese Selektion per System zu machen.

Für diese Probleme gibt es verschiedene Ursachen und verschiedene Lösungen.

Eine, die uns immer wieder auch bei den härteren Fällen hilft, ist der

WSUS Offline Updater

Seine Funktion klingt auf den ersten Blick überflüssig: Das Tool lädt Updates von den offiziellen Microsoft-Update-Quellen herunter und installiert sie dann in einem zweiten Schritt. Das hat allerdings zwei Vorteile gegenüber dem in Windows eingebauten Windows-Update:

1. Sind die Updates einmal heruntergeladen, dann kann man sie gleich auf mehreren PCs installieren, ohne sie nochmals herunterzuladen
2. Stottert das normale Windows-Update, dann schafft es der WSUS Offline Updater meistens, die Updates doch noch zu installieren

Die Nutzung ist denkbar einfach:

• Laden Sie das Tool von der Webseite des WSUS Offline Updater herunter und packen Sie in aus
• Starten Sie das UpdateGenerator.exe, wählen Sie aus, für welche Betriebssystemversionen und (allenfalls) Office-Versionen Sie Updates bereitstellen möchten
• Mehrfachnennungen sind möglich
• Klicken Sie Start
• Nach einiger Zeit sind die Updates bereit zur Installation
• Starten Sie nun im client-Verzeichnis den UpdateInstaller
• Der Bequemlichkeit halber können Sie allenfalls die Option zum automatischen Reboot anwählen
• Starten Sie den Updater per Klick auf Start

Falls Sie mehrere Windows-Installationen aufdatieren möchten, können Sie nachdem der UpdateGenerator seine Arbeit getan hat, das komplette Verzeichnis auf mehreren PCs nutzen, ohne die Updates immer wieder herunterzuladen.

Nach Fertigstellung des Updates sollten Sie nicht vergessen, Windows Update noch einmal durchzuführen – der Offline Updater erwischt nicht immer alle Updates.

Nach einigem Suchen konnten wir feststellen, dass Linux beim Zugriff auf die per Adaptec RAID 8405 eingebundenen Disk-Volumes hing. Offenbar wurde vor einiger Zeit eine Änderung im aacraid-Treiber vorgenommen, der genau die von uns beobachteten Hänger verursacht. Betroffen sind dabei unseres Wissens mindestens Debian, RedHat/CentOS, SuSE – vermutlich aber alle Distributionen.

Als Workaround hat in unserem Fall geholfen, den aacraid-Treiber mit der Option

aac_sync_mode=1"

zu verwenden. Da der Treiber bereits relativ früh im Bootprozedere benötigt wird verwenden wir die entsprechende Option bereits direkt auf der Kernel-Kommandozeile als

aacraid.aac_sync_mode=1

Unter Debian erreichen wir dies, indem wir den folgenden Eintrag in /etc/default/grub vornehmen:

GRUB_CMDLINE_LINUX="aacraid.aac_sync_mode=1" 

Nicht vergessen: Nach Modifikation der Datei muss »update-grub» ausgeführt werden.

Wie Sie Argumente zur Kernel-Kommandozeile hinzufügen ist distributionsabhängig – konsultieren Sie die jeweilige Dokumentation.

Wir stellen eine solche auf unserer Download-Seite zur Verfügung. Die Funktionsweise ist betont simpel

• es handelt sich um ein einfaches Shell-Skript
• das Sie aus Cron regelmässig (1x pro Minute ist zu empfehlen) starten
• es holt aus /var/log/syslog (Sie können es an Ihr System anpassen, indem Sie /var/log/syslog z.B. durch /var/log/messages ersetzen) Logeinträge erfolgreicher POP3/IMAP-Logins
• unter /var/spool/pop-before-smtp merkt es sich die gefundenen IP-Adressen und den Zeitpunkt, wann diese zuletzt im Log aufgetaucht sind
• aus dieser Information generiert es Einträge in /etc/mail/access und löscht sie (nach 50 Minuten) auch wieder

Die meisten Sendmail-Standardinstallationen verwenden sowieso /etc/mail/access, d.h. das Skript funktioniert sofort ohne Änderung an der Sendmail-Konfiguration. Sollte dies doch nicht der Fall sein, so lässt sich die access-Datei so in sendmail.mc konfigurieren:

FEATURE(`access_db', , `skip')dnl

Falls die Access-Datei in Ihrem Fall nicht unter /etc/mail liegt, passen Sie den Pfad im Skript an.

Trotzdem erwarten Sie bitte keine Wunder. Es handelt sich um eine schreiend einfache Quick&Dirty-Lösung, die uns auch schon aus der Patsche geholfen hat. Sie hat auch Nachteile:

• Unterstützung für Dovecot und Courier ist implementiert. Verwenden Sie einen POP/IMAP-Server, mit dem das Skript nicht zusammenarbeitet, dann müssen die grep- und sed-Anweisungen passend angepasst werden.
• Zur Zeit unterstützt das Skript IPv6-Adressen nicht
• Der Aufruf per Cron sorgt dafür, dass maximal die Zeit zwischen zwei Aufrufen vergehen kann, bis SMTP nach einer erfolgreichen Anmeldung freigeschaltet wird
• Da das Skript direkt /etc/mail/access bearbeitet, muss man bei manuellen Änderungen darauf Rücksicht nehmen, dass die Datei während des Bearbeitens auch mal aufdatiert werden kann.
• Weder das Abarbeiten des Logs per tail noch das Aufnehmen von Adressen in /etc/mail/access ist besonders elegant oder effizient und nur für kleine Mailserver geeignet. Verwalten Sie auf Ihrem Mailserver tausende von Mailboxen, dann nehmen Sie sich bitte die Zeit, eine effizientere Implementation zu verwenden oder noch besser POP-Before-SMTP auszumerzen.
• IPv6-Unterstützung fehlt noch.

• auf webbasierte Gerätekonfigurationen zuzugreifen
• Probleme der Anwender vor Ort mit dem Internetzugang nachvollziehen zu können

Tatsächlich genügt ein Shell-Zugang per SSH, um notfalls wie im entfernten Netz zu surfen. Dazu gehen wir wie folgt vor:

• einen SSH-Tunnel auf einen Rechner vor Ort aufbauen
  • per Kommandozeile (OpenSSH unter Linux oder auf dem Mac): Verwenden Sie zum Einloggen zusätzlich die Option -D 2001
  • per Putty: Navigieren Sie in der Oberfläche zu SSH / Tunnels, tragen unter Source Port 2001 ein, selektieren die Option Dynamic und fügen mit Add dieses Portforwarding hinzu. Loggen Sie sich nun wie gewohnt per Putty ein.
• Starten Sie einen Browser. In den Einstellungen (unter Windows: Internet Optionen) konfigurieren Sie einen manuellen Proxy: Geben Sie als SOCKS Host "localhost" an und als Port "2001"
• Wenn Sie nun einen URL öffnen, wird die Anforderung durch den SSH-Tunnel auf den entfernten Rechner übertragen und von diesem ausgeführt
• Beachten Sie, dass auf diese Weise die Namensauflösung immer noch lokal bei Ihnen stattfindet – Sie werden also Geräte vor Ort eher mit IP-Adresse als mit Namen ansprechen (Sie können mit der Proxy-DNS-Einstellung experimentieren, wenn Ihr Browser Sie anbietet)

Vergessen Sie nicht, nach getaner Arbeit die Proxy-Einstellung wieder zu entfernen.