CC::Blog

Schlagwort: ipv6

  • ipv6 via SIXXS und Telekom // Multihoming

    Hat man zwei ipv6-uplinks ist es wichtig, dass Connections die über Provider „A“ reinkommen, auch über Provider „A“ wieder rausgehen. Mit den default-settings ist das nicht der Fall. Wenn dort etwas via „A“ reinkommt, die default-route aber „B“ ist, versucht der Router die Antwortpakete via „B“ rauszurouten. Das geht idR schief, da der ISP meint man würde die IP faken. Aber es gibt Abhilfe:

    Folgendes SetUp nehmen wir mal an:

    [codebox 1]

    Alles was nun via eth0 (hinter dem der sixxrouter irgendwo hängt) reinkommt, will linux via ppp0 beantworten.

    Lösung: Eine rule anlegen:

    [codebox 2]

    Der Output von route und rule sollte am Ende dann wie folgt aussehen:

    [codebox 3]

     

  • Ganze Netze bei ipv6 mit fail2ban blocken

    ipv6 ist nett. Aber der User bekommt halt jedes mal idR ein /64 Subnet. Für so Tools wie fail2ban, die einzelne IPs blocken, wenn irgendetwas komisches auftaucht irgendwie schlecht. Der Angreifer schnappt sich halt irgendeine neue IP, denn die unteren 64bit stehen ja voll zu seiner Verfügung.

    Jetzt verhält es sich mit dem originalen fail2ban so, dass das nicht mal ipv6 kann. Zeit sich auf die Suche zu machen. In einem github-Repo bin ich fündig geworden. Der gute Mensch hat fail2ban so erweitert, dass es v6-fähig wird. Also flugs mal installiert, um direkt die Ernüchterung zu spüren: Es blockt mit /128 🙁

    Also erweitern:

    Die /etc/fail2ban/action.d/iptables-46-multiport-log.conf passen wir wie hier in diesem gist sichtbar an. Hinzugekommen ist lediglich <mask> bei der ban und unban-Regel sowie unter init. Das bedeutet, dass – sofern nicht anders angegeben – immer eine /32er CIDR-Mask gelegt wird, also die gesamte v4-IP (bei v6 halt ebenfalls /32 – aber dazu später mehr) geblockt wird.

    Da die fail2ban-Variante von „usrweiss“ im Wrapperscript nicht so granular zwischen v4 und v6 differenzieren kann, als dass wir da andere cidr-Masken drauflegen könnten, legen wir einfach in der /etc/fail2ban/jail.conf ZWEI Jails an:

    [codebox 1]

    Die benötigen wiederrum auch 2 Configs in der /etc/fail2ban/filter.d:

    /etc/fail2ban/filter.d/web_v4.conf:

    [codebox 2]

    /etc/fail2ban/filter.d/web_v6.conf:

    [codebox 3]

    Der Haken ist, dass unsere Applikation, die die Events auslöst (hier eine Loginseite, die die Fehlversuche nach /var/log/apache2/web_f2b/fail.log wegschreibt) an die Zeile dranschreiben muss, ob es sich um v4 oder v6 handelt. Bezogen auf die o.g. Configs sieht das in dem fail.log der App so aus (Von der Applikation generierte Einträge. Erster: v6, zweiter v4)

    [codebox 4]

    Von nun an blockt fail2ban die Ports 80 und 443 sobald in der Logdatei der Applikation (/var/log/apache2/web_f2b/fail.log) 5 mal innerhalb von 60 Sekunden die selbe IP mit einem Fehler aufschlägt für 60 Sekunden. Und zwar bei einer v4 halt die v4, bei einer v6 das /64er Subnet der v6. Die gerade greifende Netzmaske wird in der/etc/fail2ban/jail.conf als Variable „mask“ in der action mit angegeben – sollte dort nichts stehen, gilt der Defaultwert von /32 aus der iptables-46-multiport-log.conf

     

    Wie üblich, geht das sicherlich noch eleganter. Bin gespannt, wann fail2ban endlich eine v6-Variante releast.

  • IPV6 und Kontrolle übers LAN // HILFE !

    Ausnahmsweise mal keine (Über-)Lebenshilfe, sondern ein Hilferuf!

    Da hier zwei Kids rumlaufen, hab ich gern die Kontrolle wann und wie das Netz benutzt wird. Bisher (zu v4-Zeiten) hat der Squid gute Dienste geleistet. Mit ipv6 ist das nicht mehr so. Da beisse ich mir nämlich die Zähne aus.

    Doch von vorn: Hier im Netz läuft ein radvd (Router Advertising Daemon), der ein sixxs-Prefix im LAN Announced. Der (zwangs-)proxy biegt alle ausgehenden ipv4-Port-80 Anfragen transparent auf den Squid-Port um, und handlet den Kram dann per ACL. v4 gibt es statisch über einen DHCP, und für Gäste ist eine Range vergeben.

    Seit v6 schnappen sich die Endgeräte irgendeine v6-Adresse (bei ios7 kann man ja bekanntlich die privacy-extensions nicht mehr ausschalten) und vorbei ist es mit der Kontrolle (vom DNS mal ganz abgesehen). Eine Lösung muss her. Bisher ausprobiert habe ich folgendes:

    • auth_param im Squid angeknipst. Resultat erschütternd:
      • Android und Proxys … Hahaha (wenn, nur „gerooted“) !!! Android und Proxy-Auth – HEUL! Tut überhaupt nicht.
      • ios und Proxys – Nett / ios und Proxy-Auth – Neee, da taktet ein Autoblinker stabiler. Geht nicht 🙁
      • OSX: Siehe ios.
    • acl based on arp (acl arp)
      • Bei v4 schick – bei v6 gibts Neighbourdiscovery und kein arp mehr. Dummerweise scheint noch niemand ND in irgendeiner Squid-Version als acl implementiert zu haben 🙁
    • ACLs auf V6-IP-Basis
      • Aufgrund der Privacy-Extensions unbenutzbar

    Noch nicht ausprobiert (weil so demotiviert von den o.g. zwei Punkten – und tlw. auch zu aufwendig):

    • Getrennte „Netze“ mit getrennten IPv6-Prefixen um die ACLs auf Netzebene auszurollen:
      • Aufwändig !! Trennbar nur über VLANs, extra SSIDs an jedem WLAN-AP … und überhaupt
    • DHCPv6
      • will man sowas?
    • RADIUS
      • Kanonen / Spatzen und so. Neee
    • 802.1X
      • Interessanter Ansatz. Aber da fliegen auch wieder die IOS-Devices raus. Ferner gilt das selbe wie bei radius.

    Vorschläge sind mehr als willkommen. Derzeit hab ich auf der LAN-Seite des Proxies v6 wieder ausgeschaltet und arbeite mit den o.g. ARP-Filtern. Tut zumindest einigermassen. An so einem iphone lässt sich die macaddy nicht so einfach ändern. 

  • ipv6 via pppoe von der Telekom

    Seit 4 Tagen bin ich den lästigen reconnect der Telekom los. Keine Zwangstrennung mehr nach 24h. Yes !

    Wie das geht ? Ziemlich simpel. Man wechselt den Tarif beim rosa Riesen. „Call & Surf Comfort IP“ heisst das Ding. Einher mit dem Tarif geht ein SIP-Account, über den man von dort per VoIP erreichbar ist (Besonderheiten der Telekom inclusive – verfasse dazu noch einen Blogeintrag). Aufgrund dessen fällt dann nämlich die Zwangstrennung weg. Nun gut, genug Marketinggedönse. Zum eigentlichen: Wie ich ja schon gebloggt habe, bin ich zufriedener sixxs Kunde, was meine ipv6-Welt angeht. Schön statische Prefixe, soviel /56er subnetze (statisch!) wie man haben will. Eigentlich genau das, was man als Betreiber von ein paar unwichtigen Diensten im Netz so benötigt.

    Ganz gegensätzlich ipv6 bei der Telekom. Man bekommt ein /64er /56er Prefix, und das ist zu allem übel auch noch dynamisch. Sprich bei jedem Reconnect (der zwar, s.o., nur noch alle Jubelmonate kommt) gibts wieder einen neuen Prefix. Ist jetzt nicht der ultimative Brüller, denn der Sinn von ipv6 war ja genau dieses Dilemma zu lösen. – Wir erinnern uns: in den 90ern gab es die dynamische Vergabe nur, weil die ganzen ISPs mehr Kunden als ipv4-Addressen hatten – also mit ipv6 eigentlich kein Grund mehr für sowas. Die Gründe mögen vielfältig sein. Paranoide Menschen sind der Meinung, dass man mit dyn.IP’s einen Datenschutzzugewinn hat (Bullshit !), die Telekom meint, dass man statische IPs besser hochpreisig vermarkten sollte, und so on.

    Nun, was tun mit dem schwankenden ipv6-Prefix, bei dem man nichtmal ’ne DNS-Reversedelegation setzen kann ? Folgende Dinge sind mir so eingefallen:

    • Testen des sixxs.net oder HurricaneElectric-Tunnels von „aussen“ 🙂
    • Backup-Routing, falls sixxs/HE mal down sind (wobei das vermutlich tricky wird)
    • Den „User“ Kram aus dem Heimnetz über das /64 /56er routen. Alle Dienste über die statischen Netze

    Naja, wie auch immer man sich entscheidet, das ganze unter linux auf einem „Selbstbaurouter“ einzubinden bedarf ein wenig Bastelei. Was haben wir ?

    • Ein Standard DSL-Modem (Speedport 221) / kein Router (an dieser Stelle sei erwähnt, dass, entgegen irgendwelchen Aussagen, ein Modem vollkommen ausreicht (sowohl für VoIP, als auch für Entertain, sowie für ipv6) – „pppoe-Passthrough“ in einem Speedportrouter kann funktionieren, muss es aber nicht. Je puristischer, desto besser.
    • Ein lauffähiges Linux, mit dem wir schon in der Vergangenheit pppoe gemacht haben und welches die öffentliche ipv4 bekommt. – Ich nehm‘ hier Debian. Ein vorkonfektioniertes pfSense, ipcop, und wie die Distributionen so alle heissen, sollte auch gehen.
    • pppoe über rp-pppoe wie gewohnt. Hier in die /etc/ppp/options ein „+ipv6“ eintragen

    Jetzt gibts beim Reconnect zusätzlich zur ipv4 eine ipv6-LinkLocal-Adresse. Mit der kann man noch nicht so viel anfangen, denn die ist ja linklocal und damit nicht gerouted. An dieser Stelle hab ich echt am längsten (im wahrsten Sinne des Wortes) gehangen. Wie kommt man nun an die ipv6-IP ? Im Normalfall über zwei Wege. Entweder Router-Advertising, oder DHCPv6 (wobei letzteres nur bedingt empfehlenswert ist). Die Telekom announced die Prefixe per RA. Und zwar in 10 Minuten Intervallen. Was zum debuggen recht schmerzhaft ist (immer 10min. warten). Um dem geneigten Leser die Wartezeit (und das debuggen) zu verkürzen hier die Einstellungen die man am ppp0 vornehmen sollte (am besten in irgendein /etc/ppp/ip-up.d/file zur Firewall packen):

    [codebox 1]

    Sodann wirds beim nächsten RA (wie gesagt: Nur alle 10 min. !) eine öffentliche IP geben, die dann über die, oben erwähnte, LinkLocal-Adresse raus/reingerouted wird. Routen sollten automatisch gesetzt werden.

    ip6tables kann man dann nach gusto anpassen. Bei mir bekommt nur der „router“ die Dynamische-V6, da dort der (Zwangs-)Proxy mit adblocker & Co. läuft – reicht dort also. Wer das v6 im LAN nutzen möchte, dem sei der radvd (Router Advertising Daemon) ans Herz gelegt.

    Ein Grundsetup an ip6tables-Rules finden wir hier:

    [codebox 2]

    Happy v6ing !

     

    [Update 26.02.2014] Es gibt ein /56er Prefix bei der Telekom, keine /64er – löst das Problem aber nicht. Danke an den Hinweisgeber.

  • IPv6 mit Safari und einer wpad.dat

    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

    [codebox 1]

    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…

  • IPv6 via sixxs

    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 !