Mobiles Arbeiten mit Ubuntu Linux in Zügen der DB
Kurze Anleitung wie man das WLAN in Zügen der DB auch unter Ubuntu Linux mit installierten Docker nutzen kann.
Die Fahrt mit der Bahn von Berlin nach Hamburg ist ideal zum Arbeiten. Der Zug fährt gute anderthalb Stunden ohne Halt und man hat auf den meisten Abschnitte eine ausreichende Internetverbindung. Voller vorfreude und mit einer Todo-Liste im Gepäck startet ich meine Bahnfahrt. Die Ernüchterung kam schnell. Mein Laptop mit Ubuntu Mate wollte mir die Anmeldeseite für das WIFIOnICE nicht anzeigen. Mit dem Smartphone hatte ich keine Probleme, also funktionierte die Technik der DB grundsätzlich.
Aus welchem Grund wird die Seite nun nicht geladen?
Erster Check, Wifi ist verbunden und eine TCP/IP Adresse wird zugewiesen. Das hat funktioniert.
> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:64:62:21 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.25/24 brd 10.8.100.255 scope global dynamic noprefixroute enp0s3
valid_lft 28330sec preferred_lft 28330sec
inet6 fe80::6ea8:dde5:e978:15e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
An dieser Stelle viel mir der TCP/IP Bereich auf aus welchem die Addressen stammen: 172.16.255.255, 172.17.255.255 und 172.18.255.255.
Problematisch in meinem Fall ist der Bereich 172.17.255.255. Dieser wird bei mir lokal bereits von Docker verwendet.
> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:64:62:21 brd ff:ff:ff:ff:ff:ff
inet 10.8.100.229/24 brd 10.8.100.255 scope global dynamic noprefixroute enp0s3
valid_lft 28330sec preferred_lft 28330sec
inet6 fe80::6ea8:dde5:e978:15e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:95:c2:89:f0 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:95ff:fec2:89f0/64 scope link
valid_lft forever preferred_lft forever
Das erklärt, warum Firefox sich weigert die Anmeldeseite des WIFIOnICE der Bahn zu laden. Die Anfragen werden an den lokalen Docker daemon gesendet.
Lösungsalternative I – Quick and dirty
Das Problem kann durch ein deaktivieren der lokalen Docker Netzwerkschnittstelle temporär umgangen werden.
sudo ifconfig docker0 down
Jetzt sollte sich http://www.wifionice.de im Browser öffnen lassen.
sudo ifconfig docker0 up
Der Nachteil dieser Lösung ist, sie ist nicht nachhaltig. Beim nächsten Mal sind die gleichen Arbeitsschritte wieder auszuführen.
Lösungsalternative II – Dauerhafte Lösung
Unter Docker muss nich zwangsläufig der Bereich 172.17.255.255 für das Standard Bridge Netzwerk verwendet werden. In der Datei: /etc/docker/daemon.json lässt sich ein anderer TCP/IP Bereich konfigurieren. Falls die Datei nicht vorhanden ist, muss diese einfach neu angelegt werden.
> sudo nano /etc/docker/daemon.json
Ein anderen TCP/IP Adressbreich für das Standard Birdge Netzwerk festlegen.
{ "bip":"172.30.0.0/16" }
Jetzt noch einmal den Daemon durchstarten.
> sudo service docker restart
Jetzt sollte sich die Anmeldeseite unter http://www.wifionice.de im Webbrowser öffnen lassen. Dem mobilen Arbeiten als Softwareentwickler steht somit auch in Zügen der DB jetzt nichts mehr im Weg. Happy Coding!