MikroTik-Router per SSH konfigurieren

Die Router von MikroTik können auf unterschiedlichsten Wegen konfiguriert werden. Zum einen kann das Windows-Tool WinBox genutzt werden. Daneben existiert ein Webinterface und als dritte Möglichkeit der Zugang per SSH. Um sich per SSH mit dem Router verbinden zu können, muss der MikroTik-Router über eine IP-Adresse verfügen. Anschließend kann er per SSH konfiguriert werden:

ssh admin@192.168.1.1

Als Nutzername muss admin genutzt werden. Bei einem frischen System ist für den Nutzer admin noch kein Passwort gesetzt.

Nach dem Login wird der Nutzer von einem Prompt in Empfang genommen

Damit kann der Router nun über die SSH-Verbindung konfiguriert werden.

Nginx-Konfiguration per GUI

Bei der Nutzung des freien Webservers Nginx müssen für die einzelnen Domains Konfigurationen erstellt werden. Im Normalfall werden diese von Hand erstellt, allerdings existieren mittlerweile Werkzeuge, um diese auf anderem Wege zu erzeugen.

Über die Oberfläche kann eine Nginx-Konfiguration erzeugt werden

Eines dieser Werkzeuge ist nginxconfig.io. Über die Webseite kann eine Konfiguration erstellt werden, indem die gewünschten Optionen ausgewählt werden. Auch kann mit vorgefertigten Presets gearbeitet werden. Für den Einsteiger ist sicherlich interessant, dass er so ein Gefühl für Möglichkeiten von Nginx bekommt. Der Quelltext des Dienstes kann über GitHub bezogen werden. Er ist unter der MIT-Lizenz lizenziert und damit freie Software.

Maximale Größe von Mails unter Postfix konfigurieren

Standardmäßig ist die maximale Größe von Mails beim MTA Postfix auf 10240000 Byte, knapp 10 MiB, beschränkt. Soll diese Einstellung bearbeitet werden, so muss die entsprechende Konfigurationsdatei von Postfix bearbeitet werden:

nano /etc/postfix/main.cf

In der Datei muss die Option message_size_limit hinzugefügt werden:

message_size_limit = 40960000

In diesem Fall wurde die maximale Größe von Mails auf knapp 40 MiB gesetzt. Nach einem Neustart von Postfix:

service postfix restart

ist die neue Obergrenze gesetzt und Mails können bis zur entsprechenden Größe versendet werden.

Reverse Proxy für Gitea konfigurieren

Ein Reverse Proxy liefert eine Ressource, welche er von einem oder mehreren Servern holt, an einen Client aus. Bei Gitea kann es durchaus sinnvoll sein, dieses hinter einem Reverse Proxy zu betreiben. Standardmäßig läuft der Dienst auf dem Port 3000. Möchte der Nutzer ihn über die normalen Ports für HTTP (80) bzw. HTTPS (443) erreichbar machen, könnte das Ganze durchaus über die Konfiguration von Gitea in Verbindung mit der systemd-Unit geschehen.

Allerdings ist ein weiterer Vorteil bei einem Reverse Proxy, das die angefragte Infrastruktur aus der Sicht der Clients versteckt wird. Mittels Nginx kann es solcher Reverse Proxy realisiert werden. Dazu muss die Nginx-Konfiguration für die Domain angepasst werden:

nano /etc/nginx/sites-available/example

In diesem Fall befasst sich die Konfiguration mit der verschlüsselten Kommunikation per HTTPS und der Weiterleitung von unverschlüsselten Verbindung in Richtung der verschlüsselten Verbindung.

server {
  listen 80;
  listen [::]:80;

  server_name example.org;

  return 301 https://$host$request_uri$is_args$args;
}

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

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

    server_name org;

    location / {
        proxy_pass http://localhost:3000;
    }
}

Anhand der Konfiguration wird ersichtlich das Gitea auf dem Server unverschlüsselt betrieben werden kann, da die eigentliche Verschlüsselung über HTTPS vom Reverse Proxy, in diesem Fall Nginx, übernommen wird. Nachdem die Konfiguration gespeichert wurde, muss Nginx neugestartet werden:

service nginx restart

Anschließend muss die Gitea-Konfiguration nochmals angepasst werden:

nano /home/git/gitea/custom/conf/app.ini

Dort muss die ROOT_URL nun so definiert werden, wie der Client sie nun sieht. Die ROOT_URL kann von:

ROOT_URL         = https://example.org:3000/

zu:

ROOT_URL         = http://example.org/

geändert werden. Die Werte PROTOCOL, CERT_FILE und KEY_FILE können entfernt werden, da die Verschlüsslung nun von Nginx übernommen wird. Nach der Änderung der Konfiguration muss Gitea ebenfalls neugestartet werden:

service gitea restart

Nachdem die Konfiguration durch geführt wurde, ist Gitea unter zwei URLs erreichbar:

http://example.org:3000/
https://example.org/

Intern läuft Gitea auf dem Port 3000. Damit dieser nicht von außen erreichbar ist, sollte eine entsprechende Firewall-Regel konfiguriert werden.

Rewrites unter Nginx loggen

In der Konfiguration für den Webserver Nginx bzw. dessen Seiten, ist es möglich Rewrite-Direktiven zu nutzen. Damit können URLs umgeschrieben werden. Ein Beispiel für eine solche Direktive wäre z.B.

try_files $uri $uri/ @rewrite;

location @rewrite {
  rewrite ^/(.*)$ /index.php?_url=/$1;
}

Wenn dieser Rewrite zur Anwendung kommt, erscheint leider keine Meldung in den Nginx-Logs access.log und error.log. Um das Logging für Rewrites zu aktivieren, muss die Option:

rewrite_log on;

im server-Block der Konfiguration, welche unter /etc/nginx/sites-available/ zu finden ist, aktiviert werden. Daneben muss die Logging-Severity, also die Schwere der Events die geloggt werden sollen, angepasst werden. Dazu wird folgende Option dem server-Block hinzugefügt:

error_log /var/log/nginx/error.log notice;

Wenn die Log-Datei nun angeschaut wird, so finden sich dort für jeden Rewrite entsprechende Meldungen:

2019/05/29 08:35:30 [notice] 16054#16054: *127817 „^/(.*)$“ matches „/name/german“, client: 82.193.248.37, server: api.example.com, request: „GET /name/german HTTP/1.1“, host: „api.example.com“
2019/05/29 08:35:30 [notice] 16054#16054: *127817 rewritten data: „/index.php“, args: „_url=/name/german“, client: 82.193.248.37, server: api.example.com, request: „GET /name/german HTTP/1.1“, host: „api.example.com“