Jun 23

Die Konfig hier zu Haus sagt, gehe über den Proxy – egal was passiert. Per iptables ist es den Workstations verboten, direkte HTTP-Requests nach draussen abzusetzen. Die werden einfach gedroppt. Damit man jedoch nicht bei jedem neuen Client erst den Proxy eintragen muss, gibt es so schöne Erfindungen wie wpad.dat (aka proxy.pac).

Der DHCP Server im Netz announced also, bei Vergabe einer ip, gleich die URL fuer die Proxy-Autoconf mit. In der Regel klappt das auch alles super. Hätte nicht jeder Browserhersteller wieder seinen eigenen Kram gebastelt. So interpretiert der Safari auf dem Mac diverse Dinge anders als der Chrome oder der IE. Eine schöne Matrix, mit dem was geht, und was nicht geht, gibt es bspw. bei pacwpad.com.

Die Herausforderung bestand/besteht am Ende darin, den Browsern zu sagen: Hey, du willst was im LAN, dann brauchst Du den Proxy nicht zu fragen. Ansonsten bitte Proxy nehmen. Mit ipv4 kein Thema. Bei ipv6 verschluckt sich der Safari jedoch massivst.

In der folgenden Config bin ich nun soweit, dass Chrome brav das macht was er soll, Safari jedoch bei jeglichen (auch LAN) ipv6-only Websites immer über den Proxy geht. Das liegt daran, dass der Safari scheinbar die javascript-Funktion “dnsResolveEx” nicht kennt. Ohne try/exception macht der immer einen auf “direct” bei ipv6. Mit diesem Konstrukt geht er zumindest immer auf den Proxy. Bin mal gespannt, wie lange es dauert bis sich die Browserhersteller da geeinigt haben…

Hier also die Config:

  • LANv4 ist 10.0.0.0/24
  • LANv6 ist 2001:999:999:8888/64

function FindProxyForURL(url, host)
{
        if (isInNet(host, "10.0.0.0", "255.255.255.0")) { // ipv4 im LAN ? Dann direct
                return "DIRECT";
        }
        if (host.substring(0, 4) == "127.") { // Localhost ? dann DIRECT
                return "DIRECT";
        }
        if (host.substring(0,16) == "2001:999:999:8888") { // IPv6 Adresse in den Browser eingegeben, und die ist im LAN ? Dann DIRECT
                return "DIRECT";
        }
        try {
            var resolved_ip = dnsResolveEx(host);
            if (resolved_ip.indexOf("2001:999:999:8888")>-1 ) { // Hostname löst auf eine IPv6 auf, die im LAN ist ? Dann DIRECT
                    return "DIRECT";
            }
        } catch(e) { // Funktion "dnsResolveEx" nicht vorhanden ? Dann Fallback proxy
            return "PROXY 10.0.0.2:3128";
        } 
        return "PROXY 10.0.0.2:3128"; // Default: Proxy
}

									

Update: Es empfiehlt sich anstelle der IP (10.0.0.2:3128) den FQDN des Proxies einzutragen. Einige Geräte machen scheinbar einen lookup bevor sie den Proxy fragen. Wenn beim lookup eine V6 Adresse herauskommt, dann läuft die wpad.dat ins leere, da kein V6-Proxy gefunden wird. Wichtig: der FQDN des Proxies sollte sowohl über einen V4-Eintrag (A), als auch über einen V6-Eintrag (AAAA) verfügen, und auch zusätzlich auf dem V6-Port lauschen…

Tagged with:
Jun 17

So, es ist vollbracht. Die ganzen Consumer-Provider in good ‘ol Germany wollen ja irgendwie nicht so richtig mit ipv6 an den Start kommen. Also habe ich mal selbst Hand angelegt. Einen Provider hat man schnell gefunden. Ich habe mich für sixxs.net entschieden.

Bei sixxs.net bekommt man zunächst einen /64er Block für lau zugewiesen, den man hinterher auf /48 upgraden kann (Vorraussetzung: der 64er Tunnel läuft eine Woche durch / Downtimes, bspw. zum basteln, sind nicht tragisch). Einfach anmelden, “aiccu” herunterladen, konfigurieren, starten und glücklich sein. Achtung: Aiccu / sixxs.net prüft die Systemzeit – Ein NTP-Client auf dem lokalen Endpunkt hilft da ungemein !

Das 48er-Subnet benötigt man aber nicht wirklich für den Heimgebrauch. Mit dem 64er kann man die restlichen 2^64 Adressen munter im Netz verteilen. Genau da war Anfangs auch mein Denkfehler. Mir war nicht aufgefallen, dass sixxs.net ein Transfernetz zur Vefügung stellt, durch das dass /64er gerouted werden kann. Konkret sieht das ganze nach dem ersten Start wie folgt aus:

  • PtP-Adresse (Da gehts also zu sixxs): 2001:6f8:100:fea::1/128 (Die beiden :: sind die Platzhalter für gaaanz viele Nullen – ausgeschrieben sähe das ganze so aus: 2001:6f8:100:fea:0000:0000:0000:1/128)
  • Lokale Adresse des ersten “ipv6”-Interfaces: 2001:6f8:100:fea::2/64
  • Und jetzt wird’s spannend. Im Webinterface bei sixxs.net kann man sehen, dass das zur Verfügung stehende Netz 2001:6f8:100:dfea::/64 lautet (Man beachte das “d” bei Octet 7)

Mit dem dfea-Netz (die Adressen sind für den Blogeintrag gefaked) können wir nun intern loslurchen und die Rechner ausstatten. Im simpelsten Falle installiert man sich den radvd (Router Advertising Daemon) und konfiguriert sowie startet ihn. Der verteilt die Dinger dann im LAN. Achtung: Dem LAN-Interface muss man selbst eine (v6-)IP aus dem dfea-Netz verpassen (/etc/network/interfaces) – das macht der radvd nicht. Jetzt noch das ipv6-Fowarding enablen (echo 1 >/proc/sys/net/ipv6/conf/all/forwarding) und schon können alle anderen Rechner per ipv6 mit der Welt in Verbindung treten (oder auch angesprochen werden !!)

Was uns zu einem kleinen Schönheitsfehler bringt. Ich will ipv6, weil ich das genNATte und diese ewige dynamische IP-Vergabe leid bin. Dummerweise vergibt der radvd die IP’s aber höchstdynamisch. Statisch verfügbar wäre in diesem Szenario also allenfalls der Router. Schuld (- Die Diskussion will ich hier nicht führen -) sind die sog. “privacy extensions” die irgendwelche paranoiden Mitmenschen entworfen haben. Ich war schon bei v4 kein Freund von “Würfel”-DHCP. Ganz abgesehen davon möchte ICH, und nicht irgendein Billo-Router regeln, wer wann wie worüber ins Netz geht. Bei IP’s die man nicht kennt, ist das ein grausames Unterfangen.

Jetzt gibt es zwei Möglichkeiten aus dem Dilemma herauszukommen.

  1. DHCP-V6 aufsetzen (hab ich noch nicht ausprobiert) und die IP’s statisch den Mac-Adressen im LAN zuordnen.
  2. Den Servern händisch statische IP’s verpassen.
  3. Mischbetrieb aus 2 und radvd

Habe mich erstmal für Variante 3 entschieden. Also jeden Server abgrasen und eine IP aus dem dfea-Netz eintragen, Default(-v6-)Route setzen und testen. Die Arbeitsplatzrechner bekommen die IP’s per radvd, die Server sind statisch verdrahtet. Fein, funktioniert.

Jetzt kommt der fieseste Teil, an dem ich zwei Stunden versenkt habe:

Das ganze ist bei Debian nämlich leider nicht Bootfest, da Linux ganz jeck auf Route-Advertisments ist, und sich dort auch eine IP “ziehen”, wenn sie schon statisch eine abbekommen haben. Hier helft eine Kernel-Einstellung in /etc/sysctl.conf:

net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.autoconf=0

Die alleine macht aber auch noch nicht glücklich, da die sysctls beim booten eingelesen werden sollen. Zu diesem Zwecke linkt man sich die /etc/init.d/procps in die runtimelevel-Dirs (/etc/rcX.d/). Hilft auch noch nicht, weil: Die Einstellungen greifen nur, wenn auch das ipv6-Kernel Modul schon geladen ist – sonst laufen die ins leere 🙁 Hierzu ipv6 in die /etc/modules eintragen. Anschliessend booten – et voila: Es läuft !

Jetzt fehlt eigentlich nur noch eins: Eine ordentliche Firewall mit Connection-Tracking. Gibts wohl demnächst mal einen Blogeintrag drüber. Soviel sei gesagt: Connectiontracking geht erst ab Kernel 2.6.26, redirect (bspw. für transparente Proxies) erst ab 2.6.36…

Somit wäre dieses Blog nun auch via ipv6 erreichbar !

Tagged with:
preload preload preload