{"id":196,"date":"2014-11-15T17:11:09","date_gmt":"2014-11-15T16:11:09","guid":{"rendered":"http:\/\/3ronco.vahanus.net\/?p=196"},"modified":"2019-01-24T09:26:28","modified_gmt":"2019-01-24T08:26:28","slug":"ipv6-pppd-router-advertisements-via-icmpv6","status":"publish","type":"post","link":"https:\/\/3ronco.vahanus.net\/?p=196","title":{"rendered":"IPv6, pppd & Router Advertisements via ICMPv6"},"content":{"rendered":"

Baut man \u00fcber den pppd<\/em> eine DSL Verbindung auf, so erh\u00e4lt man normalerweise die Adresse des Peers<\/em> und die \u00f6ffentliche IP-Adresse.<\/p>\n

14: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3\n    link\/ppp\n    inet 0.1.2.3 peer 4.5.6.7\/32 scope global ppp0<\/pre>\n
Bei IPv4<\/em> ist das nichts ungew\u00f6hnliches allerdings ist es erstaunlich dass wenn man dasselbe \u00fcber IPv6<\/em> versucht man u.U. nur eine Link-Local<\/em>-Adresse erh\u00e4lt:<\/p>\n
inet6 fe80::10:20:30:40\/10 scope link\n  valid_lft forever preferred_lft forever<\/pre>\n
Bei IPv6<\/em> werden neue Router bzw. Netze durch das sogenannte Neighbor Discovery Protocol<\/em> (vgl. Router Advertisement<\/a>) dem lokalen Netz mitgeteilt. Klappt das nicht k\u00f6nnten paranoide Admins schuld sein die wider besseren Wissen s\u00e4mtlichen ICMP<\/em> Verkehr mit der Firewall<\/em> blockieren. Obwohl Router Advertisement<\/em> durchaus f\u00fcr b\u00f6se Dinge eingesetzt werden k\u00f6nnen allerdings nur dann wenn man sie \u00fcber Netzgrenzen hinweg gestattet. Das Router Advertisement<\/em> g\u00e4nzlich zu filtern ist jedenfalls eine denkbar unflexible L\u00f6sung da sie dann im internen, lokalen Netz genauso wirkt wie aus dem WAN<\/em> heraus. Im lokalen Netz jedenfalls ist sowas oft unerw\u00fcnscht zumindest wenn man sich die IPv6 Stateless Autoconfiguration<\/em> zu nutze machen m\u00f6chte und in unserem Fall setzt PPPoE<\/em> sie f\u00fcr IPv6<\/em> sogar voraus. Deswegen sollte man bei der Diagnose erstmal ausschlie\u00dfen das die eigene Firewall<\/em> dazwischen friemelt.
\n
\nAllerdings gibt es auch einige Kernel<\/em>-Parameter (z.B. accept_ra<\/em>) die das Verhalten von netfilter<\/em> auch ohne eigene Firewall<\/em> beeinflussen und diese k\u00f6nnte in der Standartkonfiguration zu restriktiv eingestellt sein:<\/p>\n
root@myHost:~ # for sz in \/proc\/sys\/net\/ipv6\/conf\/*\/accept_ra; do echo \"$sz=$(cat $sz)\"; done;\n\/proc\/sys\/net\/ipv6\/conf\/all\/accept_ra=1\n\/proc\/sys\/net\/ipv6\/conf\/default\/accept_ra=1\n\/proc\/sys\/net\/ipv6\/conf\/eth0\/accept_ra=1\n\/proc\/sys\/net\/ipv6\/conf\/eth1\/accept_ra=1\n\/proc\/sys\/net\/ipv6\/conf\/eth2\/accept_ra=1\n\/proc\/sys\/net\/ipv6\/conf\/lo\/accept_ra=1\n\/proc\/sys\/net\/ipv6\/conf\/ppp0\/accept_ra=1\n<\/pre>\n
Aha, schauen wir uns dazu mal die Definitionen an:<\/p>\n
accept_ra - INTEGER\n Accept Router Advertisements; autoconfigure using them.\n\n It also determines whether or not to transmit Router\n Solicitations. If and only if the functional setting is to\n accept Router Advertisements, Router Solicitations will be\n transmitted.\n\n Possible values are:\n  0 Do not accept Router Advertisements.\n  1 Accept Router Advertisements if forwarding is disabled.\n  2 Overrule forwarding behaviour. Accept Router Advertisements\n    even if forwarding is enabled.\n\nFunctional default: enabled if local forwarding is disabled. disabled if local forwarding is enabled.<\/pre>\n
Man sollte also \/proc\/sys\/net\/ipv6\/conf\/default\/forwarding=1<\/em> aktiviert haben, seltsamerweise erhalte ich trotz gesetztem \/proc\/sys\/net\/ipv6\/conf\/default\/accept_ra=1<\/em> Parameter nur eine Link-Local<\/em>-Adresse. Abhelfen kann man sich hier indem man die Forwarding<\/em> Einstellung schlicht ignoriert und damit Router Advertisement<\/em> grunds\u00e4tzlich akzeptiert z.B. durch \/proc\/sys\/net\/ipv6\/conf\/ppp0\/accept_ra=2<\/em>.
\nDie paranoiden Admin d\u00fcrften nun mittlerweile im Dreieck springen und diesmal nicht ganz zu unrecht, so eine Einstellung sollte man nicht als Standard f\u00fcr alle Ger\u00e4te setzen denn es w\u00fcrde Angreifern erlauben \u00fcber jede Netzwerkverbindung dem LAN<\/em> neue Netzwerke anzuk\u00fcndigen unabh\u00e4ngig davon ob der betreffende Host<\/em> nun ein Router<\/em> ist oder nicht. Daher werden wir nur dem ppp0<\/em> Ger\u00e4t diese Einstellung erlauben.<\/p>\n
Als ersten L\u00f6sungsansatz kommt einem vielleicht folgendes in den Sinn, in der \/etc\/network\/interfaces<\/em> Konfigurationsdatei setzt man im pre-up<\/em> Ereignis:<\/p>\n
...\niface dsl0 inet ppp\n pre-up echo 2 > \/proc\/sys\/net\/ipv6\/conf\/ppp0\/accept_ra<\/span>\n provider telekom\n...<\/pre>\n
Leider klappt das nur f\u00fcr Ger\u00e4te die zu diesem Zeitpunkt dem System wirklich bekannt sind also z.B. eth0, eth1, …<\/em> da aber das ppp0<\/em> ein virtuelles Ger\u00e4t ist das erst mit dem Start von pppd<\/em> sein Leben beginnt, ist dieser Ansatz zum scheitern verurteilt. Wer das up<\/em> statt dem pre-up<\/em>-Ereignis verwendet stellt ern\u00fcchtert fest dass es dann schon wieder zu sp\u00e4t ist denn die PPP Negotiation<\/em> ist zu dem Zeitpunkt bereits vollst\u00e4ndig ausgef\u00fchrt. Man kann hier nachtr\u00e4glich mit Werkzeugen wie rdisc6<\/em> basteln allerdings mu\u00df man dann mit allerlei Bash-KungFu daf\u00fcr sorgen das diese IP<\/em> auch dem System bekannt gemacht werden, zu aufwendig und fehleranf\u00e4llig.
\nAuch der Versuch diese Konfiguration via sysctl<\/em> Einstellung zu setzen ist problematisch:<\/p>\n
root@myHost:~ # cat \/etc\/sysctl.conf | grep accept_ra\nnet.ipv6.conf.ppp0.accept_ra=2<\/pre>\n
Dann funktioniert zwar der erste Verbindungaufbau beim Bootvorgang noch aber alle nachfolgenden Verbindungen zeigen wieder das urspr\u00fcngliche Fehlerverhalten und das ist auch logisch weil nachdem einmal eine ppp0<\/em>-Verbindung abgerissen wurde wird \/proc\/sys\/net\/ipv6\/conf\/ppp0\/accept_ra<\/em> wieder durch \/proc\/sys\/net\/ipv6\/conf\/default\/accept_ra=1<\/em> auf den Standart zur\u00fcckgesetzt.
\nAbhilfe schafft hier eine udev Rule<\/em> die den Wert jedesmal setzt wenn das ppp0<\/em> Ger\u00e4t im System angelegt wird z.B. durch:<\/p>\n
root@myHost:~ # cat \/etc\/udev\/rules.d\/21-ppp.rules \n# allow router advertisment only for ppp0 and only when it comes up!\nKERNEL==\"ppp0\", SUBSYSTEM==\"net\", ACTION==\"add\", RUN+=\"\/bin\/bash -c 'echo 2 >\/proc\/sys\/net\/ipv6\/conf\/ppp0\/accept_ra'\"<\/pre>\n
Ein Blick offenbart nun das gew\u00fcnschte Resultat bei jedem Start des pppd<\/em> erh\u00e4lt man eine \u00f6ffentliche, anklingelbare IPv6<\/em>-Adresse:<\/p>\n
root@myHost:~ # ip -6 addr show dev ppp0\n23: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qlen 3\n    inet6 2003:40:1111:2222:3333:4444:5555:6666\/64 scope global temporary dynamic \n       valid_lft 14291sec preferred_lft 1691sec\n    inet6 2003:40:1111:2222:3333:4444:5555:7777\/64 scope global dynamic \n       valid_lft 14291sec preferred_lft 1691sec\n    inet6 fe80::1111:2222:3333:4444\/10 scope link \n       valid_lft forever preferred_lft forever<\/pre>\n
Das sch\u00f6ne an dieser L\u00f6sung ist, wer seinen paranoiden Tendenzen weiterhin fr\u00f6nen m\u00f6chte k\u00f6nnte theroretisch das Filtern<\/em> des betreffenden Router Advertisement<\/em> Pakets zumindest f\u00fcr den Zeitraum indem die PPP-Verbindung aufgebaut wird gestatten. Sollte die Verbindung wieder stehen und die Firewall<\/em> wieder aktiv sein w\u00fcrden zuk\u00fcnftige Router Advertisement<\/em> Anfragen blockiert.<\/p>\n","protected":false},"excerpt":{"rendered":"
Baut man \u00fcber den pppd eine DSL Verbindung auf, so erh\u00e4lt man normalerweise die Adresse des Peers und die \u00f6ffentliche IP-Adresse. 14: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3     link\/ppp     inet 0.1.2.3 peer 4.5.6.7\/32 scope global ppp0 Bei IPv4 ist das nichts ungew\u00f6hnliches allerdings ist es erstaunlich dass wenn man […]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[12,39,11,10,29,9],"class_list":["post-196","post","type-post","status-publish","format-standard","hentry","category-bb","tag-accept_ra","tag-administration","tag-icmpv6","tag-ipv6","tag-linux","tag-pppd"],"_links":{"self":[{"href":"https:\/\/3ronco.vahanus.net\/index.php?rest_route=\/wp\/v2\/posts\/196","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/3ronco.vahanus.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/3ronco.vahanus.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/3ronco.vahanus.net\/index.php?rest_route=\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/3ronco.vahanus.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=196"}],"version-history":[{"count":18,"href":"https:\/\/3ronco.vahanus.net\/index.php?rest_route=\/wp\/v2\/posts\/196\/revisions"}],"predecessor-version":[{"id":915,"href":"https:\/\/3ronco.vahanus.net\/index.php?rest_route=\/wp\/v2\/posts\/196\/revisions\/915"}],"wp:attachment":[{"href":"https:\/\/3ronco.vahanus.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=196"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/3ronco.vahanus.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=196"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/3ronco.vahanus.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=196"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}