SFP-VDSL-Modem auf einem MikroTik-Router einrichten

Reine VDSL-Modems sind eine aussterbende Art. Trotzdem gibt es noch hier und da entsprechende Modems, unter anderem im SFP-Standard. Diese SFP können genutzt werden z.B. einen MikroTik-Router mit einer entsprechenden Funktionalität nachzurüsten. In diesem Fall sollte es die Möglichkeit sein VDSL über das Interface sfp1 zu nutzen. Die erhältlichen SFP-Module für VDSL sind meist baugleich mit dem VersaTec VX-160CE VDSL2-SFP.

Ein VDSL Modem als SFP

Nachdem das Modul im MikroTik-Router installiert wurde, ist das Interface sfp1 aktiv. Die Auto Negotiation muss für das Modul deaktiviert werden. Andernfalls schlägt später die Neuverbindung nach einem Neustart fehl, da das Modul nicht mehr erkannt wird.

Die Auto Negotiation muss für das Modul deaktiviert werden

Eingestellt wird das Modul hierbei auf 1Gbps bei Full Duplex. Im nächsten Schritt muss ein VLAN für die Schnittstelle angelegt werden. Hintergrund ist, das erwartet wird das die Daten sich im VLAN mit einer bestimmten ID befinden. Bei der Deutschen Telekom ist dies die 7, bei anderen Anbietern kann dies teilweise abweichen. So z.B. bei 1&1; dort wird je nach genutzter Infrastruktur die 7 oder die 8 genutzt.

Das VLAN-Interface

Beim anzulegenden VLAN-Interface ist darauf zu achten, das kein Service-Tag gesetzt wird. Nachdem das Interface sfp1 und das entsprechende VLAN-Interface konfiguriert sind, kann im nächsten Schritt die PPPoE-Verbindung eingerichtet werden. Dazu wird unter PPP ein neues PPPoE-Interface eingerichtet. Das zu nutzende Interface für das PPPoE-Interface ist hierbei das VLAN-Interface, im Beispiel sfp1-v7.

Das PPPoE Interface

Im Tab Dail Out müssen die Zugangsdaten von Internetanbieter eingetragen werden. Im Falle einiger Anbieter wie z.B. 1&1 kann es notwendig sein vor dem eigentlichen Nutzernamen ein H zu setzen, da dieser sonst nicht akzeptiert wird und der Authentifizierungsvorgang fehlschlägt. Damit ist das SFP-Modul eingerichtet und die Verbindung kann genutzt werden. Je nach genutztem Modell aus der MikroTik-Palette kann es sein, das nicht die volle Bandbreite genutzt werden kann. Das Problem ist in diesen Fällen meist die CPU-Auslastung durch die PPPoE-Verbindung da diese komplett durch die CPU verarbeitet werden muss. In einem solchen Fall kann zu den Cloud Core.Routern von MikroTik gegriffen werden.

Nachdem die Verbindung hergestellt war, stellte ich im Laufe eines längeren Testes allerdings fest, dass der PPPoE-Link in regelmäßigen Abständen nach 30 – 80 Minuten zusammenbrach und somit leider kein stabiles Internet lieferte. Vermutlich handelt es sich um ein Problem des SFP-Moduls im Zusammenhang mit dem DSLAM.

Maven-Repository in Eigenregie hosten

Wenn mittels Maven eine Abhängigkeit zur pom.xml-Datei, wie in folgendem Beispiel, hinzugefügt wird:

<dependency>
	<groupId>org.slf4j</groupId>
	<artifactId>slf4j-api</artifactId>
	<version>1.7.26</version>
</dependency>

versucht Maven diese Abhängigkeit von Maven Central, dem zentralen Repository, zu beziehen. Es ist allerdings möglich Abhängigkeiten aus anderen Repositories zu beziehen. Dazu muss der repositories-Block zur pom.xml hinzugefügt werden.

<repositories>
	<repository>
		<id>example</id>
		<url>https://repository.example.org</url>
	</repository>
</repositories>

Aus Nutzersicht ist die Konfiguration von Maven damit erledigt. Soll ein solches Maven-Reposity aufgesetzt werden, ist dies relativ einfach möglich. Dazu wird ein Verzeichnis per HTTP über den Webserver Nginx ausgeliefert. Innerhalb dieses Verzeichnisses wird ein gesicherter Ordner erstellt, welcher über WebDAV erreicht werden kann. Die entsprechende Nginx-Konfiguration sieht für diesen Fall wie folgt aus:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/repository.example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/repository.example.org/privkey.pem;

        root /var/www/example/repository;

        server_name repository.example.org;

        location / {
                autoindex     on;
        }

        location /upload {
                dav_methods     PUT DELETE MKCOL COPY MOVE;
                dav_ext_methods   PROPFIND OPTIONS;

                dav_access    user:rw group:rw all:rw;

                create_full_put_path  on;

                autoindex     on;

                auth_basic "restricted";
                auth_basic_user_file /var/www/example/repository/upload/.htpasswd;
        }
}

Die .htpasswd-Datei, welche für die Authentifizierung benötigt wird, kann mit dem Tool htpasswd erstellt werden:

htpasswd -c .htpasswd nutzer1

Bei der Nutzung wird das gewünschte Passwort erfragt. Soll ein weiterer Nutzer hinzugefügt werden, so muss der Parameter -c entfernt werden:

htpasswd .htpasswd nutzer2

Anschließend wird die Konfiguration von Nginx mittels:

service nginx reload

aktualisiert. Danach kann WebDAV für die Ressource verwendet werden. In der pom.xml-Datei für das Projekt, welches ein Artefakt für das Repository erzeugt, wird der build-Bereich erweitert und der distributionManagment-Bereich hinzugefügt:

            </plugin>
        </plugins>
        <extensions>
            <extension>
                <groupId>org.apache.maven.wagon</groupId>
                <artifactId>wagon-webdav-jackrabbit</artifactId>
                <version>3.2.0</version>
            </extension>
        </extensions>
    </build>
    <distributionManagement>
        <repository>
            <id>example</id>
            <url>dav:https://repository.example.org/upload/</url>
            <layout>default</layout>
        </repository>
    </distributionManagement>
</project>

Im Extension-Bereich wird das Wagon-Plugin für WebDAV aktiviert. Dieses sorgt dafür das die Artefakte per WebDAV zum Repository hochgeladen werden. In dem distributionManagment-Bereich wird die WebDAV-URL definiert. Wenn nun ein:

mvn deploy

durchgeführt wird, wird dies allerdings nicht funktionieren. Hintergrund ist das der upload-Ordner per Basic authentication geschützt ist. Die Zugangsdaten für diese Authentifikation müssen noch hinterlegt werden. Natürlich werden diese nicht in der pom.xml hinterlegt, da dies aus Gründen der Sicherheit keine gute Idee wäre. Stattdessen werden die Daten in der settings.xml hinterlegt. Diese befindet sich im Pfad:

~/.m2/settings.xml

In dieser Datei wird eine server-Sektion mit den Zugangsdaten hinzugefügt:

<settings>
	<servers>
		<server>
			<id>example</id>
			<username>example</username>
			<password>password</password>
		</server>
	</servers>
</settings>

Anschließend kann das Artefakt erfolgreich mittels:

mvn deploy

in das Repository hochgeladen werden. Problematisch ist das sich die Daten nur im upload-Verzeichnis und nicht im eigentlichen Verzeichnis des Repository liegen. Zur Lösung hierfür wird ein Cronjob, im Kontext des Nutzers www-data, angelegt:

sudo -u www-data crontab -e

Ziel des Cronjobs ist es die Daten aus dem upload-Verzeichnis regelmäßig in das eigentliche Verzeichnis des Repository zu kopieren:

*/5  *    * * *   cp /var/www/example/repository/upload/* /var/www/example/repository/ -r

Damit wird alle 5 Minuten der Inhalt des uploadVerzeichnisses in das Repository kopiert. Ein Verschieben kann leider nicht durchgeführt werden, da die Metadaten beim jeden Deployment von Maven eingelesen werden und erweitert werden. Hier könnten Optimierungen durchgeführt werden, so das alle Dateien bis auf die Metadaten verschoben werden. Soll ein nicht öffentliches Repository erstellt werden, kann auf den zusätzlichen upload-Ordner verzeichnet werden und das Hauptverzeichnis selber per WebDAV befüllt werden. So lange die Zugangsdaten für den Server in der settings.xml-Datei hinterlegt sind, können seitens Maven die entsprechenden Artefakte bezogen werden.

WebDAV unter Nginx einrichten

Der freie Webserver Nginx beherrscht nicht nur das gewöhnliche Ausliefern von Daten über HTTP und HTTPS, sondern verfügt daneben über weitere Module. Mit einem dieser Module kann WebDAV für eine Ressource bereitgestellt werden.

WebDAV steht dabei für Web-based Distributed Authoring and Versioning und basiert auf HTTP. Über WebDAV können Dateien im Internet bereitgestellt werden. Unter anderem ist WebDAV deshalb so interessant weil es die gleichen Ports wie HTTP nutzt und somit in den seltensten Fällen blockiert wird.

Zur Nutzung des Modules für WebDAV muss die Konfiguration der jeweiligen Seite unter /etc/nginx/sites-available/ angepasst werden. In diesem Beispiel wäre dies:

nano /etc/nginx/sites-available/example

Zur dieser Konfigurationsdatei wird folgende Konfiguration hinzugefügt:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;

        root /var/www/example;

        server_name example.org;

        location / {
                dav_methods     PUT DELETE MKCOL COPY MOVE;
                dav_ext_methods   PROPFIND OPTIONS;
                dav_access    user:rw group:rw all:rw;

                autoindex     on;
        }
}

In diesem Fall wird für die Domain example.org die WebDAV-Unterstützung aktiviert. Dateien können hierbei ohne weitere Authentifizierung herunter- und hochgeladen werden. Soll WebDAV abgesichert werden, so geschieht das über den Basic authentication. Dazu wird dem location-Part folgendes hinzugefügt:

auth_basic "restricted";
auth_basic_user_file /var/www/example/.htpasswd;

Die .htpasswd-Datei kann mit dem Tool htpasswd erstellt werden:

htpasswd -c .htpasswd nutzer1

Bei der Nutzung wird das gewünschte Passwort erfragt. Soll ein weiterer Nutzer hinzugefügt werden, so muss der Parameter -c entfernt werden:

htpasswd .htpasswd nutzer2

Anschließend wird die Konfiguration von Nginx mittels:

service nginx reload

aktualisiert. Danach kann WebDAV für die Ressource verwendet werden.

Zwei-Faktor-Authentifizierung unter GitHub aktivieren

Mit einer Zwei-Faktor-Authentifizierung ist ein Account im Falle eines Passwortverlustes geschützt, da ein zweiter Faktor benötigt wird. Auch GitHub unterstützt seit einiger Zeit eine solche Authentifizierung. Auf der entsprechenden Nutzerseite findet man den Punkt Enable two-factor authentification.

GitHub unterstützt zwei Varianten der Zwei-Faktor-Authentifizierung

GitHub unterstützt zwei Varianten der Zwei-Faktor-Authentifizierung

Nachdem diese Option ausgewählt wurde, muss sich entschieden werden, ob man die Authentifizierung per SMS oder entsprechender Authentifizierungsapp, wie dem Google Authenticator, einrichten möchte.

‎Google Authenticator
Preis: Kostenlos
Google Authenticator
Preis: Kostenlos

Bei der Einrichtung muss ein Sicherheitscode (nach der Einrichtung der App, bzw. per SMS zugesendet) eingeben werden, um die Zwei-Faktor-Authentifizierung zu aktivieren. Danach werden Recovery-Codes von GitHub angezeigt, welche unbedingt gesichert werden sollten, da mit diesen auch bei Verlust des Authentifizierungsgerätes ein Zugriff auf das GitHub-Konto erhält.