Apr 15

LongMessages vs Concatenated via SMSC

Linux, Netz, Work No Comments »

Kurzer Merker für mich (Bezgl.: Endgeräte werden in bestimmten Konstellationen bei überlangen SMS zugespammt.)

Beim Versand von SMSsen über UCP/EMI (Command 51) gibt es zwei Möglichkeiten wie man mit “überlangen” SMS (>160 GSM-Chars) umgehen kann:

  1. Concatenated Messages. Man teilt die Messages in 160er Chunks auf und sendet im UDH (User Data Header) folgendes für die Einzelteile:
    1. 0x00 = Concatenated Message
    2. 0x03 = Länge des Infoelements (Folgt jetzt)
    3. 0xC0 = Referenz-ID (kann ausgewürfelt werden. Ist Unique auf Receipient und diese ID)
    4. 0x02 = Anzahl der einzelnen Mulitpart-SMSsen
    5. 0x01 = Diese Message ist Part 1 von dem was in Byte 4 steht.
  2. LongMessage (Feature muss SMS-C seitig aktiviert sein). In dem Falle geht das Ding mit dem Standard UDH in einem Block raus (Maximale Länge ist beim SMSC zu erfragen – in meinem Fall waren 550 Chars durchaus machbar)

So, und nun wird es spannend.

Acknowledgehandling

Im Fall 1 wird

  • jeder einzelne Part fein vom SMSC eingequed,
  • ans SS7 überstellt und
  • für jeden einzelnen Part ein ACK generiert – SS7 generiert das Acknowledge, wenn die (Teil-)Message beim Empfänger angekommen ist, und übergibt das ACK dann ans SMSC welches dieses per UCP/EMI an mich weitergibt.

Das ist ne ziemlich zeitaufwendige Angelegenheit, die man wirklich extrem spürt. Der Durchsatz SMS/sec ist halt nur 1/n so groß wie wenn ich nur eine 160er Nachricht versende (n=Anzahl der Parts).

Fall 2 ist da schon (vermeintlich) eleganter. Wir überstellen den “Blob” ans SMS-C und bekommen (bei erfolgreicher delivery) genau ein ACK zurück. Und hier liegt der Hase im Pfeffer. Aufgefallen ist mir das ganze, weil es Empfänger gibt, die sich bei mir über nicht aufhörend wollende SMSsen beschwert haben (Empfänger bekommt die selbe SMS wieder und wieder. Hört so gut wie nicht auf. 2000 sind keine seltenheit). Also der Sache auf den Grund gegangen:

  1. die LongMessages werden per UCP/EMI mit ACK-Req (ohne geht nicht) ans SMSC übergeben.
  2. SMSC schiebt die LongMessage ans SS7 durch.
  3. SS7 merkt “Oh, ne LongMessage” und splitted die in 160er Chunks (Auch wenn es LongMessages gibt. GSM/SMS kann – egal wie – nur 160er Chunks)
  4. Gleichzeitig schiebt das SS7 ein(!) ACK ans SMS-C zurück, wenn der erste Part zugestellt wurde.
  5. ACK kommt via UCP/EMI bei mir an

Schaut man sich das jetzt genauer an, stellt man fest, dass das ACK schon beim ersten erfolgreichen Zustellversuch des ersten Chunks kommt. Jetzt gibt es da draussen irgendwelche irren Endgeräte, die das ACK in genau diesem Fall nicht sauber senden. Mit dem unschönen Nebeneffekt, dass das SMSC für die nicht geackten Chunks immer wieder dem SS7 auf die Füße tritt (“Send nochmal”). Je nach unglücklicher Konstellation ist das Endgerät nun in einem ewigen loop.

Fragt mich bitte nicht, warum das im Fall 1 nicht auch passiert. Laut meinem SMSC Kontakt liegt es am Zusammenspiel SMSC/SS7. Einzige Abhilfe war, alles auf MuPart umzustellen. Mit all den häßlichen Nebenwirkungen bezgl. Durchsatz und Co.

Ich denke die einzige Alternative dagegen wäre es, sich selbst ein SS7-Account zu besorgen. Ob man das aber will (zum rumspielen bestimmt mal gerne – aber produktiv)…

 

Vielleicht hat ja einer meiner Leser da ein paar mehr Hintergründe (Jetzt bitte kein: Nimm doch SMPP. Hat sich nämlich rausgestellt, dass überall wo “Simple” im Protokollnamen vorkommt, es alles andere als Simpel ist. Stehe nicht so auf irre XML/SOAP-Requests)

Tagged with: • • • • • • • • • • •
Dez 13

ipv6 via SIXXS und Telekom // Multihoming

Linux, Netz No Comments »

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:

ppp0 (Telekom): 2003:1::2 mit aktiver default gw ppp0
eth0 (sixxs): 2001:2::2 mit NICHT aktiver default-GW 2001:2::1

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

Lösung: Eine rule anlegen:

echo "100 sixxs" >> /etc/iproute2/rt_tables
/sbin/ip -6 rule add from 2001:2::/64 lookup sixxs
/sbin/ip -6 route add default via 2001:2::1 dev eth0 table sixxs

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

router:~# ip -6 rule
0:  from all lookup local 
16383:  from 2001:2::/64 lookup sixxs 
32766:  from all lookup main

router:~# ip -6 route
2001:2::/64 dev eth0  proto kernel  metric 256 
2003:1::2 dev ppp0  proto kernel  metric 256 
default via fe80::10ca dev ppp0  metric 1024  initcwnd 10 initrwnd 10

router:~# ip -6 route list table sixxs
default via 2001:2::1 dev eth0  metric 1024

 

Tagged with: • • • • • •
Mai 31

Ganze Netze bei ipv6 mit fail2ban blocken

Allgemein, Linux, Netz No Comments »

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:

[web_v4]
enabled = true
filter  = web_v4
action = ip64tables-multiport-log[name=web_v4, protocol="tcp", port="80,443", mask=32]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60

[web_v6]
enabled = true
filter  = web_v6
action = ip64tables-multiport-log[name=web_v6, protocol="tcp", port="80,443", mask=64]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60

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

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

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#

[INCLUDES]

[Definition]

failregex = Applikation: v4 (<HOST>) Detaillierte Fehlermeldung .*

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

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#

[INCLUDES]

[Definition]

failregex = Applikation: v6 (<HOST>) Detaillierte Fehlermeldung .*

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)

[May 31 10:08:12] Applikation: v6 (2a03:2880:2130:cf05:face:b00c:0:1) fehlerhafter Loginversuch blabla
[May 31 10:09:12] Applikation: v4 (173.252.120.6) fehlerhafter Loginversuch blabla

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.

Tagged with: • • • • • • • • • • • • • • • • • •
Mai 02

Beonderheiten des Mobilen Internets

Netz No Comments »

Für mich selbst als Merker, damit ich das nächste mal nicht wieder in Panik ausbreche.

Besonderheiten beim “Internet” via Telekom Hotspot:

  • Öffentliche IP’s gibt es per se nicht – man bekommt irgendwas privates aus dem 10er-Space zugewiesen.
  • V4 only
  • Jede Ziel-IP (egal ob Online oder Offline) ist aus dem Hotspot-Netz ein DNS-Server. Führt zu leichten Panikattacken, wenn man meint seine eigenen Kisten von aussen damit auditieren zu wollen. Vermutung: Alles was auf Port 53 rausgeht, wird von der T abgefangen und dann unter falscher Flagge beantwortet, als wäre es ein openrelay.

Besonderheiten beim “Internet” via Telekom LTE:

  • Öffentliche IP’s gibts mit LTE nicht mehr (LTE akzeptiert ausschliesslich “internet.telekom” oder “internet.t-mobile” als APN – und da gibts halt nur “Private-Address-Space”)
  • v4 Only
  • Port 80 und Port 8080 unterliegen irgendeiner Art Deep-Packet-Inspection (kann nur raten, ob das was mit diesem Zwangsproxy zu tun hat, der jpgs/gifs noch mal nachkomprimiert hat). Fakt ist: Egal ob die Ziel-Adresse offline ist, oder gar keinen Dienst auf den beiden Ports anbietet – es gibt IMMER einen sauberen 3-Wege Handshake. Interessant in dem Zusammenhang: Irgendein Netzelement leitet die Anfragen (so denn die “Echte Ziel-IP” online ist, und auch n Listener hat) mit leichtem Delay an die Richtige IP weiter. Wenn Ziel-IP offline / kein Dienst, gibts ein “FIN” per TCP – aber erst nach erfolgtem SYN/SYNACK/ACK.
Tagged with: • • • • • • • • • • • • • •
Jun 10

Umstieg auf Android // Ein paar Erfahrungen

Allgemein, Linux, Netz 6 Comments »

Schreibe hier mal nach und nach ein paar hilfreiche Erfahrungen auf, wenn man – wie ich – den Schritt von IOS nach Android wagt, und von der ganzen Cloud-Struktur nicht so viel hält.

Ein wenig eigene Infrastruktur je nach Geschmack (Mailserver, CAL-/CARDDAV-Server, Proxy mit adblocker nach gusto, eigener DNS) sollte es jedoch schon sein, wenn man die wichtigsten Daten von der Cloud fernhalten möchte. Das war unter ios so, und gilt unter Android mehr denn je. Also los gehts mit den Basics:

  • Mails: Da eignet sich K9-Mail ganz gut – ist etwas anders als Mail.App zu bedienen, kann aber nach meinen Vertestungen am meisten
  • Kalendersync: CalDAV-Sync integriert den eigenen CalDAV zu 100% in die Android-Welt, und das ganz ohne gmail-Kalender. Reminder und Co. funktionieren sauber!
  • Telefonbuch: CardDAV-Syncfree synct wunderfein die Kontakte mit dem heimischen CardDAV-Server (zum einsatz kommt hier übrigens davical)
  • Notizen: Werden bei ios/osx als “spezielle Mail” in einem Subfolder mit Namen “Notes” abgelegt. Da gibts was günstiges für den Droiden: iNotes – nicht von der Beschreibung im Store verwirren lassen, der spielt echt mit jedem imap (hier ist der gute alte cyrus im Einsatz)
  • Twitter: Tja. Da bin ich noch nicht so ganz weiter. Tweetbot gilt nach wie vor als ungeschlagen. Aber Tweetveo kommt zumindest schon mal etwas dran. [Update 10.06.14] Plume isses ! Tweetmarker-Support. Suchen nach Antworten – also all das was Tweetbot auch kann – zumindest auf den ersten Blick. Danke an @bridgerdier [Update 05.12.2014] Fenix ist der Twitterclient der Wahl
  • Newsreader: Original tt-rss Client für tinytiny – geht doch 🙂

Nun bringt das alles herzlich wenig, wenn man die Äpps auf dem Device, sowie das OS nicht einigermassen abschotten kann. Und an dem Punkt kommt Cyanogenmod – das mich überhaupt bewegt hat, von IOS nach Android zu wechseln – ins Spiel. Nicht ganz trivial zu installieren (Grobe Vorgehensweise: Bootloader unlocken, CWM/TWM aufspielen, Image installieren) aber in der Version 11 (Analog KitKat) sehr empfehlenswert. So lässt sich jede Äpp beliebig kastrieren (Bis hin zu: “Darf die App vibrieren?” und so). Ein Feature das google seit 4.4.2 wieder ausgebaut hatte. Hier isses drin. Und das ganze CM11 ist echt stabil.

Wer dann den Droiden noch weiter abschotten möchte, dem sei (CM11 bzw. root vorrausgesetzt) noch Droidwall ans Herz gelegt. Ganz platt gesagt ist Droidwall ein Frontend für iptables mit dem man pro Äpp sagen kann, ob diese überhaupt ins Netz darf. Heisst: Wenn ich bspw. ne Taschenlampe installiere, dann braucht die mal definitiv keinen Netzzugriff… Logging gibts gratis obendrauf.

Ansonsten macht AdFree von BigTinCan noch den solidesten Eindruck. Warum das Teil von einer sehr dubiosen Website kommt, nicht im Playstore verfügbar ist und überhaupt, weiss wohl niemand. Habe dieses Ding ausgewählt, weil es ganz simpel die /etc/hosts um einschlägige Werber ergänzt, und echt nicht mehr anstellt. Alles andere wollte direkt Nutzungsdaten und Co. nach Hause funken. Dieses schicke kleine APK macht genau das was es soll (Werbung fernhalten – und das auch noch relativ elegant).

[Update 11.06.14] Mit IOS8 soll es ein Update geben, bei dem das iPhone die Mac-Adresse des WLAN-Interfaces randomisiert während es keinerlei Connect zu einem WLAN hat. Löbliches Feature. Geht mit dem Droiden natürlich auch. Guckst du Pry-Fi im Playstore. Das das Teil root-Rechte benötigt, liegt auf der Hand.

Am meisten weggetan hat das Messaging. Kenne ich doch recht viele ios-iMessage Menschen. Da gibt es leider nur Pest oder Cholera als Ersatz. Facebook möchte ich nun nicht gerade in Form von WhatsApp beglücken, also hab ich mich neben SMS für Google-Hangouts entschieden. Ob bei Kurznachrichten jetzt Apple oder google mitliest ist da relativ. (Nur FB sollte es halt nicht sein). Das ganze Thema Messaging ist extremst unbefriedigend, sowohl unter ios als auch unter Android. Diesen ganzen Placeboteile wie Threema und wie sie nicht alle heissen kann man auch nicht trauen (ist halt kein opensource). Daher gibts hier halt einen Kompromiss.

Wenn jemand noch weitere Tips hat, immer gern her damit.

Gesucht wird bspw. noch:

  • PodFetcher
  • FeedReader (Gut, Feeds lese ich hauptsächlich auf dem iPad – aber wer weiss: Vielleicht kommt da ja auch irgendwann mal ein Droide hin)
  • …
Tagged with: • • • • • • •
Jan 25

GPG / PGP Key beglaubigen

Allgemein, Linux, Netz No Comments »

Gaaaanz kurze knackige Anleitung, wie man einen PGP/GPG Key beglaubigt  bzw. signiert (unvollständig, und OHNE Anleitung, wie man den Key auf korrektheit prüft – idealerweise signiert Ihr nur Keys, bei denen Ihr 100%ig sicher seid, dass diese auch vom passenden Keyowner kommen 🙂 )

Shell:

[gpg –list-keys] Pub-Key-ID des zu signierenden keys merken

[gpg –sign-key <pubkeyid>] Das eigentliche Signieren

[gpg –send-keys <pubkeyid>] Signieren dem Keyserver bekanntmachen

OSX / GPGTools:

  • GPG Schlüsselbund (GPG Keychain) starten.
  • Rechte Maustaste auf den zu signierenden Key
  • Beglaubigen anclicken, Details entsprechend wählen und OK drücken
  • Wieder rechte Maustaste, diesesmal “Öffentlichen Schlüssel an Schlüsselserver senden”

Der letzte Punkt – also das Veröffentlichen der Beglaubigung, wird gern vergessen. Ohne diesen Schritt ist das ganze jedoch recht witzlos.

[UPDATE]

Bei mehreren uids (Identitäten) pro Key:

  • Doppelclick auf den Key in der Keychain-GUI
  • Wechsel auf den “Benutzer-ID”-Tab
  • Zu bestätigende Identität OBEN auswählen
  • Unten auf das Plus clicken und beglaubigen
  • Anschliessend wieder raus, und “Öffentlichen Schlüssel an Schlüsselserver senden” (s.o.)
Tagged with: • • • • • • • • • • • • •
Jan 12

IPV6 und Kontrolle übers LAN // HILFE !

Netz 5 Comments »

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. 

Tagged with: • • • • • • • • •
Jan 12

Tiny Tiny RSS updated nicht mehr

Linux, Netz No Comments »

TT-RSS an sich ist ja eine feine Sache. Das Ding hat allerdings ein/zwei Haken, wenn man es für mehrere Leute hosted. Ich nutze das hier mit dem Fever-Plugin, damit man die Feeds auch einigermassen elegant auf mobilen Endgeräten nutzen kann.

Meist ist es ja so, dass $user sich eine Feedliste zusammenstellt, und sich dann Wochenlang nicht mehr ins Frontend einloggt (Hab ich beim Google-Reader damals™ auch so gemacht). Das nimmt einem ttrss aber übel. Denn nach 30 Tagen (Einstellbar in der ./include/rssfuncs.php // Zeile 2) sagt sich ttrss: Nee, der User hat sich seit 30 Tagen nicht mehr eingeloggt, dann update ich halt nicht mehr. Pikanterweise zählt der Fever-Login nicht (Plugins verwalten Ihre Daten “irgendwie” anders – PHP-Magic halt).

Also merken: Wenn tt-rss nicht mehr updatet, entweder:

  • Zeile 2 der ./include/rssfuncs.php anpassen und hochdrehen (Halte ich für nicht so super)
  • Den/Die User/in anhalten, sich von Zeit zu Zeit mal ins Frontend einzuloggen
  • Oder (superschmutzig), per Hand das Feld last_login in der tabelle ttrss_users auf “NOW()” updaten.

 

Tagged with: • • • • • • • • •
Dez 13

ipv6 via pppoe von der Telekom

Linux, Netz 21 Comments »

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):

echo 0 > /proc/sys/net/ipv6/conf/ppp0/forwarding
echo 1 > /proc/sys/net/ipv6/conf/ppp0/autoconf

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:

/sbin/ip6tables -P INPUT DROP
/sbin/ip6tables -A INPUT -i lo -j ACCEPT              #allow everything out
/sbin/ip6tables -A INPUT -p icmpv6 -j ACCEPT
/sbin/ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/ip6tables -A INPUT -i $LAN -j ACCEPT       # allow GRE
/sbin/ip6tables -A INPUT -i $WAN -j LOG --log-prefix "INP6:End "
/sbin/ip6tables -A INPUT -i $WAN -j DROP

### OUTPUT
### (connections with the router as source)
echo "BASE OUTPUT"

  # base case
/sbin/ip6tables -A OUTPUT -o $WAN -j ACCEPT              #allow everything out
/sbin/ip6tables -A OUTPUT -o $LAN -j ACCEPT              #allow everything out

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.

Tagged with: • • • • • • • • • • • •
Jun 23

IPv6 mit Safari und einer wpad.dat

Allgemein, Linux, Mac, Netz No Comments »

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

IPv6 via sixxs

Allgemein, Linux, Netz 2 Comments »

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: • • • • • • • • • • •
Mrz 15

Internetexplorer Altlasten

Netz, Work 1 Comment »

Wer bei einem Kunden Webanwendungen einführt, welcher nach Jahren immer noch den IE6 (ja, Internetexploder Version sechs !) einsetzt, der muss sich heutzutage immernoch mit dessen inkompatbilitäten herumschlagen. Nun gut, auf einigen Kisten läuft schon der IE8, allerdings hat irgendein schlauer Admin in den IE-Einstellungen das Häkchen bei “Intranetsites in Kompatibilitätsansicht anzeigen”  gesetzt. Angeblich geht das über die Gruppenrichtlinien (von den MS-Jüngern liebevoll “GruRiLis” genannt – dass alleine ist schon einen Facepalm wert).

Jetzt will ich aber partout nicht in irgendwelchen IE-Modi arbeiten. Der “Kompatibilitätsmodus” ist nämlich in Wahrheit ein Inkompatibilitätsmodus, der dem IE sagt – Hey, Du kannst zwar W3C-Standard, aber render das mal im IE6/7 Format. Die MSDN (MasoSadoDistributionNetwork) sagt: Meta-Tag setzen (<meta http-equiv=”X-UA-Compatible” content=”IE=edge” />). Klappt aber (erwartungsgemäss) nicht.

An der Stelle sei eine Frage erlaubt: Wenn der international angehauchte Developer unter dem Schlagwort “Intranetsites in Kompatibilitätsansicht anzeigen” nichts findet (was nicht allzu unwahrscheinlich ist, da sich mit dem Dreck keiner auseinandersetzen will), was googlet man da ?

Egal – zurück zum Thema – sonst laufe ich noch Amok: Ein zusätzlicher HTTP-Header mit dem schicken Namen “X-UA-Compatible:” schafft dann doch tatsächlich abhilfe. Setzt man also in den HTTP-Header  (NICHT zu verwechseln mit dem HTML-Head Element) X-UA-Compatible: IE=IE8, dann klappt es auch mit dem W3C-Standard.

Mal wieder typisch MS: Einen Workaround anbringen, den auch noch frecherweise mit “nicht Kompatibilitätsmodus verwenden” bezeichnen, um Standardrendering hervorzurufen.

Andrererseits: Es wäre vermutlich zuviel verlangt gewesen, dass MS mal die Biege bekommt, und alte Zöpfe abschneidet. Hat alles sein für und wieder.

Disclaimer: Dieser Blogeintrag enthält zynische Bestandteile und ist rant-frei – wer will, darf die behalten 🙂

Tagged with: • • • • • • • •
Dez 06

SmartUPS on Fire

Allgemein, Linux, Netz, Work 1 Comment »

Args. Was ein pfu. Doch von vorne:

Am Freitag letzter Woche ging es los. Meine gute SmartUPS 1500RM hatte auf einmal Hitzewellen. Woher die kamen ? Keine Ahnung. Entdeckt habe ich das ganze eher durch Zufall, da ich ab und an dann doch mal einen Blick ins cacti werfe. Da sah das ganze dann so aus:Hitzewellen in der APC 1500 Interessant in dem Zusammenhang: Die USV wirft erst einen Alert ab ca. 60 Grad Celsius. Meiner Meinung nach – die sollte sich später noch bestätigen – viel zu spät. Das Rack, indem sich die APC 1500 befindet, hat übrigens direkte Aussenbelüftung – im “Serverraum” waren es also die ganze Zeit über so um die 16 Grad. Bei den Peaks bin ich dann doch mal ‘runter gegangen und hab die Schranktür des Racks aufgemacht, und siehe da: Temp wieder normal.

Am Wochenende stand das gute Stück also erstmal unter Beobachtung. Wie man oben erkennt, war es jedoch ruhig. Pünktlich zum Wochenbeginn fing die USV dann aber wieder an zickig zu werden. Da mir dass ganze (wörtlich !) zu heiss wurde, habe ich mich dann entschlossen das Batterypack (ist in so einer Cartridge) zumindest abzuklemmen. Da die Notstromversorgung Hot (!)-Pluggable ist, also kein Problem.

Sofern die angeschlossenen Geräte in diesem Zustand (Batterien abgezogen / disconnected) noch laufen, sollte man es tunlichst unterlassen der USV den Strom zu klauen. Nicht nur, dass dann alles aus ist – das wäre zu einfach – man bekommt auch keinen Saft wieder auf die USV. Die lässt sich nämlich nur mit angepömpelten Akkus starten (FAIL !!).

Also erstmal Ersatzakkus bestellen. Aber € 520,- für ‘ne Cartridge (RBC24) mit 4 Moppedakkus ? Ja sind die wahnsinnig bei APC ? Das muss doch günstiger gehen. Geht es: Diverse Händler verkaufen die Akkus einzeln zum Stückpreis von € 20,- . Da die Akkus bisher noch nicht eingetroffen sind, spreche ich da noch keine Empfehlung aus 🙂

Demontage:

Ansich nett gedacht. Frontblende der UPS entfernen, 4 Schrauben lösen und dann einfach die Cartridge mit den 4 Bleigelakkus rausziehen. Was aber tun, wenn die Dinger aufgequollen sind ? Mit Gewalt ziehen, hat geholfen. Hier das Resultat:

Nun “nur noch” die 4 Akkus aus der Blechwanne entfernen. Haha ! Kein Tutorial, keine versteckte Klammer mit der die Dinger da gehalten werden – nix. Fühlt sich an wie festgeklebt. So war es auch. Jeder Akku ist mit einem dusseligen doppelseitigem Klebestreifen an der Wanne festgeklebt. (2ter FAIL !!) Also auch hier wieder Gewalt anwenden, und die Dinger vorsichtig mit dem Schraubenzieher anhebeln – irgendwann kommen die von alleine 🙂 Der Sicherheit halber, habe ich die Anschlüsse mal zusammengetaped, isoliert, und mit Nümmerchen versehen. Jeder Platz in der Aluwanne hat dann die korrespondierende Nummer bekommen. Jetzt heisst es warten auf die Ersatzlieferung, und hoffen das der Strom nicht ausfällt.

PS: Vor ca. 6 Jahren ist mir mal eine 750er Desktop-SmartUPS unterm Schreibtisch hochgegangen. War nicht lustig. Die musste ich mit dem Topflappen auf den Balkon befördern… Von daher: Wenn Euch die Akku-Temperatur (Internal Temperature bei APC) komisch vorkommt – lieber heute als morgen die Akkus wechseln.

Tagged with: • • • • • • • • • • • •
Jun 16

MACAdressen-GeoSuche

Aus dem Leben, Netz No Comments »

Interessant. Wenn man bei eBay oder sonstwo einen Accesspoint schiesst, hat man gute Chancen anhand der WLAN-Mac-Adresse herauszufinden, wo genau der vorher stand. Nämlich via: http://samy.pl/androidmap/

Wie’s funktioniert ?

Google’s Android logged den lieben langen Tag sämtliche WLAN-Geräte im Umkreis mit und schickt die MAC-Adresse angereichert um die Geo-Koordinaten an google. Da ist natürlich mächtig was zusammengekommen. Da Google den schlimmbimm als API anbietet, kann man also jetzt Rückwärts, sofern MAC-Addresse bekannt, schauen wo das Ding steht…

Für die “nicht-techies”: Jedes WLAN-Gerät (und auch sonstige “Netz”geräte) hat eine Mac-Adresse, nicht nur Apple-Produkte *g*

Da gehen sie also hin, unsere Daten….

Tagged with: • • • • • • •
Aug 27

Fotosuchmaschine / Rückwärts

Allgemein, Canon DSLR, Netz 2 Comments »

Eine etwas andere Suchmaschine ist TinyEye. Man lädt ein Foto hoch (oder gibt den Link zu selbigem an), und TinyEye sagt einem dann, wo genau dieses Bild noch auftaucht. Um mal eben zu checken, ob sich jemand mit fremden Fotos schmückt (Gerade in den Printmedien sehr beliebt – ich sag nur “Quelle: Internet”) eignet sich das Ding prima. Ca. 1,7Mrd. Bilder sind dort indiziert. Als Sahnehäubchen kann man tinyeye auch via REST-API ansprechen.

Tagged with: • • • • • • •
Previous Entries
preload preload preload