Springe zum Inhalt

So merkwürdig der Titel klingt, denn im allgemeinen möchte man die Seiten seiner Webseite ja eher gerne in den Google-Suchmaschinen-Index aufgenommen sehen, so ergibt sich doch ab und an die Anforderung, eine Seite oder z.B. Bilder nicht in den Google-Index aufnehmen zu lassen.

Verzeichnisse mit robots.txt ausschließen

Früher konnte man das relativ einfach durch einen Eintrag in der Datei robots.txt, welche im Hauptverzeichnis der Webseite liegen muss regeln. Zu beachten ist jedoch, dass die Crawler der verschiedenen Suchmaschinen sich nicht daran halten müssen. Google jedenfalls beachtete den Inhalt dieser Datei. So z.B. konnte man mit folgendem Eintrag ein bestimmtes Verzeichnis ausschließen:

User-agent: *
Disallow: /verzeichnis/

In der ersten Zeile wird festgelegt, für welche Crawler folgende Angaben gelten sollen. Hier im Beispiel durch die Angabe eines Sterns für alle Crawler. In der zweiten Zeile erfolgt dann die Angabe eines Verzeichnisses, welches vom Crawler nicht besucht werden soll.

Einsatzgebiete für diese Methode könnte etwa sein, das Verzeichnis mit JavaScript-Dateien vom Crawlen auszuschließen.

Leider kann diese Methode seit kurzem nicht mehr verwendet werden, wenn Pfade in der robots.txt eingetragen werden sollen, deren Inhalte für das Rendern der Webseite in einem Browser erforderlich sind, so z.B. oben erwähnte JavaScript-Dateien. Google versucht seit längerem, die Seiteninhalte anhand ihrer grafischen Darstellung zu analysieren. Dazu muss die entsprechende Seite natürlich von Google gerendert werden. Ressourcen, auf die nicht zugegriffen werden kann, erzeugen dann eine Fehlermeldung.

Seiten mit META-Angaben ausschließen

Die bewährte Methode, um Seiten von der Indexierung auszuschließen, ist eine spezielle META-Angabe im Kopf der HTML-Datei zu machen. Innerhalb des Elements <head> trägt man dazu z.B. Folgendes ein:

<meta name="robots" content="noindex" />

Damit wird der Googlebot angewiesen, die Datei nicht zu indexieren. Ohne weitere Angaben folgt der Crawler jedoch den Links in der Datei, um andere Seiten zu finden. Weitere Möglichkeiten, um dem Googlebot z.B. auch das Folgen der Links zu verbieten finden sich in der unten angegebenen Google-Hilfeseite.

Problematisch bei dieser Methode ist, dass sie nur auf HTML-Dateien angewendet werden kann. Bilder und JavaScript-Dateien haben keinen solchen Eintrag. Hier bleibt nur folgendes Verfahren:

Ressourcen mit HTTP-Headerangaben ausschließen

Für diese Methode wird der Zugang zur Webserverkonfiguration benötigt. Der Webserver muss angewiesen werden, für die auszuschließenden Seiten oder Dateien einen speziellen Antwort-Header einzufügen. Um die Seite oder Datei komplett vom Index auszuschließen muss z.B. folgender HTTP-Header gesendet werden:

X-Robots-Tag: noindex

Die Angaben hinter X-Robots-Tag sind dabei die gleichen, wie sie auch in der robots.txt verwendet werden können.

Apache - X-Robots-Tag einfügen

An ensprechender Stelle der Webserverkonfiguration muss z.B. Folgendes eingetragen werden:

<Files ~ "\.(png|jpe?g|gif)$">
  Header set X-Robots-Tag "noindex"
</Files>

Zu beachten ist, dass für die Direktive "Header" das Modul mod_headers im Apache geladen sein muss.

Nginx - X-Robots-Tag einfügen

Analog wird in die Serverkonfiguration von Nginx Folgendes eingetragen:

location ~* \.(png|jpe?g|gif)$ {
	add_header X-Robots-Tag "noindex";
}

Überprüfen kann man die korrekte Ausgabe der HTTP-Header anschließend mit dem Browser. In Firefox und auch Chrome kann durch Drücken von F12 ein Fenster für Webentwickler geöffnet werden. Im Tab Netzwerk und nach dem Neuladen der jeweiligen Webseite kann man sich alle gesendeten wie auch vom Webserver empfangenen HTTP-Header anschauen.

Weitere Informationen zu diesem Thema findet man auf einer entsprechenden Hilfeseite von Google.

Noch bis zum 14.06.2015 läuft bei Conrad eine Aktion, bei der Vorschläge für ein 3D-druckfähiges Raspberry Pi 2 Case eingereicht werden können. Es werden die drei kreativsten Vorschläge ausgewählt und die Gewinner erhalten ihr Gehäuse ausgedruckt aus dem 3D-Drucker. Anschließend wird noch ein Hauptgewinner ermittelt, der zusätzlich ein von Conrad zusammengestelltes "Raspberry Pi 2 Model B Advanced-Set 1 GB" erhält.

Mehr Informationen und den Modalitäten sind auf einer eigens für diese Aktion eingerichtete Webseite zu erfahren.

1

Die Kombination aus FusionPBX und FreeSwitch stellt eine einfach zu installierende "Voice over IP"-Telefonanlage bereit, die für Privatanwender als auch für anspruchsvolle Lösungen interessant und einsatzfähig ist.

Nach der Installation und dem Durchführen der ersten Schritte sind Telefonate im internen Netz möglich. Bei ausgehenden Anrufen legt einem allerdings die Telekom einige Steine in den Weg. Die Telekom-VoIP-Server akzeptieren nicht irgendwelche Absenderadressen wie z.B. die intern gesetzte Extension. Ohne Anpassung werden Anrufe dann nur mit einem Statuscode "407 Forbidden" quittiert.

Ausgehende Anrufe

Für ein Gateway zur Telekom muss immer die korrekte Telekom-Telefonnummer als Absender in den SIP-Nachrichten mitgeteilt werden. In FusionPBX kann die korrekte Nummer unter Dialplan -> Outbound Routes eingestellt werden. Vor der Aktion bridge müssen folgende Aktionen eingefügt werden:

FusionPBX Outgoing Routes Settings

Für effective_caller_id_number und effective_caller_id_name muss die vollständige Telefonnummer inklusive Vorwahl angegeben werden. Damit erhalten alle ausgehenden Anrufe über dieses Gateway die von der Telekom geforderte Rufnummer.

Eingehende Anrufe

Da man mit einem Telekom-VoIP-Anschluss grundsätzlich drei Telefonnumern erhält (analog ISDN), ist es naheliegend, in FusionPBX drei Gateways mit je einer Rufnummer einzurichten. FusionPBX verwendet allerdings zur weiteren Verarbeitung des eingehende Anrufs den Usernamen, welcher bei allen Telekom-Rufnummern gleich ist. Eine Behandlung des Anrufs pro Rufnummer ist dadurch nicht möglich.

Abhilfe schafft der Eintrag der eigenen Telefonnummer pro Gateway. In FusionPBX erreicht man das mit folgenden Einstellungen beim entsprechenden Gateway unter Accounts -> Gateways:

FusionPBX Gateway Telekom Settings

  • Gateway: frei wählbarer Name des Gateways
  • Username: Telekom E-Mail-Adresse, z.B. mustermann@t-online.de
  • Password: das für Webzugriff im Telekom-Kundencenter eingestellte Kennwort
  • From User: eigene Telefonnummer inklusive Vorwahl
  • Proxy und Realm: tel.t-online.de
  • Extension: eigene Telefonnummer inklusive Vorwahl

Mit den obigen Einstellungen sind Anrufe nach Extern möglich, da sie entsprechend den Telekom-Anforderungen gesendet werden. Ebenso ist eine Unterscheidung der eingehenden Anrufe nach den eingestellten Rufnummern möglich.

Mit der Version 2.2.1 von pfSense wurde der alte DNS Forwarder durch den DNS Resolver Unbound ersetzt. Nach dem Update konnte nahtlos umgeschaltet werden, bei Neuinstallationen wird der DNS Resolver als Default eingestellt.

Probleme gibt es allerdings, wenn im alten DNS Forwarder Source-IPs für feste Domain-Weiterleitungen eingetragen sind. Diese werden benötigt, wenn z.B. eine Firmendomain von einem über IPSEC erreichbaren Firmen-DNS aufgelöst werden soll. Der neue DNS Resolver bietet solch eine Einstellung nicht. Ohne besondere Einstellungen werden die DNS-Requests zwar an den richtigen entfernten DNS addressiert, aber über das Default-Gateway und nicht über den IPSEC-Tunnel abgesendet.

Abhilfe schafft hier, beim DNS Resolver unter Outgoing Network Interfaces nur das LAN-Interface auszuwählen.

Nach bisherigen Tests werden damit Anfragen an Domains aus den Domain Overrides mit der korrekten Source-IP versehen. Alle anderen Anfragen an externe (z.B. per PPPoE oder DHCP erhaltene) DNS werden korrekt maskiert.

Weitere Informationen im pfSense-Forum.

Seit der Version 2.2.1 von pfSense lief mein ALIX-Router nicht mehr stabil. Das Problem trat auf, wenn von Remote durch einen IPSEC-Tunnel die pfSense-Box angesprochen wurde, z.B. die Verwaltungsoberfläche aufgerufen wurde. Resultat war ein sofortiger Kernel-Crash.

Anscheinend tritt das Problem nur unter NanoBSD und dann auch nur auf 32bit-Systemen auf. Genau so ein System ist mein ALIX 2D13 Board.

Die pfSense-Entwickler haben einen Woraround gefunden. Unter System -> Advanced -> System Tunables trägt man folgendes ein:

net.inet.ipsec.directdispatch=0

Anschließend startet man den IPSEC-Dienst neu und ab da schnurrt die pfSense-Box wieder wie eh und je.

Weitere Informationen im pfSense-Forum.

Update vom 28.06.2015: Ab der Version 2.2.3 von pfSense wird obige Einstellung auf 32bit-Systemen automatisch durchgeführt.