...
 
Commits (2)
......@@ -43,7 +43,7 @@ IPv6 Adresse.
# linux
ping6 ff02::1%br0
# windows
ping ping6 ff02::1%3
ping ff02::1%3
```
Handelt es sich bei beiden Systemen (Sender und Empfänger) um Linux, findet man
......
---
author: christian
title: NGINX Reverse Proxy durch Forward Proxy mit socat
language: german
tags: [http, nginx]
---
Wie bereits in [einem früheren Beitrag][nginx-forwardproxy]
beschrieben, kann man mit `proxy_pass` Anfragen durch einen
Forward Proxy leiten, in dem man als Proxy URL einfach den
Forward Proxy verwendet und via `proxy_set_header` den `HOST` header
auf das eigentliche Ziel einstellt.
[nginx-forwardproxy]: {{ site.baseurl }}{% post_url 2019/2019-08-12-nginx-reverseproxy-through-forward-proxy %}
Im Testbetrieb hat sich nun aber heraus gestellt, dass dies nur mit HTTP
Traffic funktioniert. Soll eine TLS Verbindung aufgebaut werden, schlägt
dies fehl, da NGINX nicht in der Lage ist den PROXY CONNECT Prozess korrekt
auszuführen.
Zur Rettung kommt hier das Tool [socat](http://www.dest-unreach.org/socat/),
welches ganz offiziell und ohne Tricks einen Proxy Connect beherrscht:
```sh
socat TCP4-LISTEN:8443,reuseaddr,fork,bind=127.0.0.1 \
PROXY:corporate-proxy.serverless.industries:webservice.example.com:443,proxyport=8080
```
Das ganze als systemd unit:
```ini
[Unit]
Description=Socat API Proxy
After=network.target
[Service]
ExecStart=/usr/bin/socat TCP4-LISTEN:8443,reuseaddr,fork,bind=127.0.0.1 PROXY:corporate-proxy.serverless.industries:webservice.example.com:443,proxyport=8080
Restart=on-failure
Type=simple
[Install]
WantedBy=multi-user.target
Alias=socat-api-proxy.service
```
In der NGINX Konfiguration wird dann der socat Port verwendet:
```
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name webserviceproxy.serverless.industries;
ssl_certificate /etc/ssl/http/bundle_serverless.industries.cert;
ssl_certificate_key /etc/ssl/http/serverless.industries.key;
location / {
proxy_set_header Host webservice.example.com;
proxy_pass https://localhost:8443;
}
}
```
Quelle: [https://stackoverflow.com/a/46824465](https://stackoverflow.com/a/46824465)
---
author: christian
title: Docker Container via Volume finden
language: german
tags: [docker, ansible]
---
Hat [acme.sh][acmesh] neue Zertifikate erzeugt welche anschließend mit
[Ansible][ansible] auf die jeweiligen Server Systeme verteilt werden,
müssen neben normalen systemd Services auch Docker Container neu gestartet
werden, welche die Zertifikate via Volume eingebunden haben.
[acmesh]: https://github.com/Neilpang/acme.sh
[ansible]: https://www.ansible.com/overview/how-ansible-works
```yml
# install jq as a dependency on the remote system
-
name: Install jq
package:
name: jq
state: present
# do a inspect on all docker containers,
# search with jq in the JSON for all
# containers which using a volume path starting with /etc/letsencrypt
-
name: Find container which are using certificates
shell: "docker inspect $(docker ps --format \"{{'{{'}}.ID{{'}}'}}\") | jq '[ .[] | { name: .Name, mounts: [ .Mounts[].Source ] } | select(.mounts | any(startswith(\"/etc/letsencrypt/\"))).name ]'"
register: certcontainersresult
# deserialize the json for ansible
# use an empty array if the string is empty
-
name: Parse docker inspect output
set_fact:
certcontainers: "{{('[]' if certcontainersresult.stdout == '' else certcontainersresult.stdout) | from_json}}"
# loop through all containers and restart them
-
name: Restart all containers which using one of the certs
docker_container:
name: "{{item}}"
state: "started"
restart: yes
loop: "{{certcontainers|default([])}}"
```
Der `docker inspect` Befehl liefert JSON, welches mit dem sehr praktischen Tool `jq` durchsucht
werden kann. Als Ergebnis dieses Befehls erhält man ein einfaches JSON Array mit
allen Container Namen welche Lets Encrypt Zertifikate verwenden:
```json
[
"/container01",
"/container02"
]
```
Der JSON String kann anschließend von Ansible deserialisiert werden und
in der `loop` Anweisung zum Container Neustart verwendet werden.
---
author: christian
title: Zahlen und .NET GUIDs kodieren
language: german
tags: ['CSharp', '.NET']
---
Diverse Webservices erwarten bei der Anlage eines Jobs als
Identifikationsmerkmal eine GUID (zum Beispiel `c4a583ad-9d39-4580-928b-c9a3dbcc6599`)
welche anschließend zum Abrufen vom Ergebnis des Jobs verwendet wird.
Verknüpft man diese Job GUID mit Daten in der eigenen Datenbank,
kann man sich eine separate Spalte oder gar ganze Tabelle sparen,
in dem man einfach den vorhandenen Primary Key als GUID kodiert.
In C# ist eine Zahl vom Typ `long` 8 Byte lang. In ein `Guid` Object passen
16 Byte. Man kann also ohne Probleme zwei `long`
Werte in eine GUID kodieren:
```cs
// Encode
long numberOne = long.MinValue;
long numberTwo = long.MaxValue;
byte[] guidBytes = new byte[16];
BitConverter.GetBytes(numberOne).CopyTo(guidBytes, 0);
BitConverter.GetBytes(numberTwo).CopyTo(guidBytes, 8);
var guid = new Guid(guidBytes);
```
Wieder dekodieren funktioniert ähnlich simpel:
```cs
// Decode
var guid = "...";
var reverseGuid = Guid.Parse(guid);
var reverseGuidBytes = reverseGuid.ToByteArray();
long numberOne = BitConverter.ToInt64(reverseGuidBytes, 0);
long numberTwo = BitConverter.ToInt64(reverseGuidBytes, 8);
```
Reichen zwei Zahlen nicht, sollte man
einen Blick auf die anderen Datentypen die C# beherrscht werfen.
Zum Beispiel gibt es da noch `short` und `ushort`.
Das Kodieren sollte aber so gebaut sein, dass Exceptions geworfen werden,
wenn sich eine Eingabe außerhalb des darstellbaren Bereichts befindet!
---
author: christian
title: NGINX Reverse Proxy durch Forward Proxy mit socat
language: german
tags: [http, nginx]
---
Wie bereits in [einem früheren Beitrag][nginx-forwardproxy]
beschrieben, kann man mit `proxy_pass` Anfragen durch einen
Forward Proxy leiten, in dem man als Proxy URL einfach den
Forward Proxy verwendet und via `proxy_set_header` den `HOST` header
auf das eigentliche Ziel einstellt.
[nginx-forwardproxy]: {{ site.baseurl }}{% post_url 2019/2019-08-12-nginx-reverseproxy-through-forward-proxy %}
Im Testbetrieb hat sich nun aber heraus gestellt, dass dies nur mit HTTP
Traffic funktioniert. Soll eine TLS Verbindung aufgebaut werden, schlägt
dies fehl, da NGINX nicht in der Lage ist den PROXY CONNECT Prozess korrekt
auszuführen.
Zur Rettung kommt hier das Tool [socat](http://www.dest-unreach.org/socat/),
welches ganz offiziell und ohne Tricks einen Proxy Connect beherrscht:
```sh
socat TCP4-LISTEN:8443,reuseaddr,fork,bind=127.0.0.1 \
PROXY:corporate-proxy.serverless.industries:webservice.example.com:443,proxyport=8080
```
Das ganze als systemd unit:
```ini
[Unit]
Description=Socat API Proxy
After=network.target
[Service]
ExecStart=/usr/bin/socat TCP4-LISTEN:8443,reuseaddr,fork,bind=127.0.0.1 PROXY:corporate-proxy.serverless.industries:webservice.example.com:443,proxyport=8080
Restart=on-failure
Type=simple
[Install]
WantedBy=multi-user.target
Alias=socat-api-proxy.service
```
In der NGINX Konfiguration wird dann der socat Port verwendet:
```
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name webserviceproxy.serverless.industries;
ssl_certificate /etc/ssl/http/bundle_serverless.industries.cert;
ssl_certificate_key /etc/ssl/http/serverless.industries.key;
location / {
proxy_set_header Host webservice.example.com;
proxy_pass https://localhost:8443;
}
}
```
Quelle: [https://stackoverflow.com/a/46824465](https://stackoverflow.com/a/46824465)
---
author: christian
title: NGINX Benutzerdefiniertes Caching
language: german
tags: [http, nginx]
---
NGINX ermöglicht es einem Upstream Server über [magische Headers][magic-headers]
Einstellungen zu ändern. Zum Beispiel mit `X-Accel-Expires`, wie lange das Response
vom Reverse Proxy geacached werden soll.
Sehr praktisch wenn man ein extrem komplexes Caching Setup umsetzen will.
Man kann durch diesen Header im Code des Upstream Server steuern, wie lange gecached wird.
[magic-headers]: https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/
In dem man zwei NGINX Reverse Proxy `server {}` Blöcke hintereinander schaltet, kann man
auch dem User erlauben eine Cache Zeit festzulegen:
```
proxy_cache_path /tmp/cache levels=1:2 keys_zone=examplecache:10m max_size=50g inactive=86400 use_temp_path=on;
server {
listen 127.0.0.1:7443 ssl;
ssl_certificate /etc/ssl/http/bundle_example.com.cert;
ssl_certificate_key /etc/ssl/http/example.com.key;
location / {
# set the cache time for examplecache by request header
add_header X-Accel-Expires $http_x_cache_ttl;
add_header Cache-Control max-age=$http_x_cache_ttl;
# ignore cache headers from upstream
proxy_ignore_headers X-Accel-Redirect X-Accel-Expires X-Accel-Limit-Rate X-Accel-Buffering X-Accel-Charset Expires Cache-Control Vary;
proxy_hide_header Cache-Control;
proxy_hide_header Via;
# remove our custom headers for upstream
proxy_set_header X-Cache-TTL "";
# relay the request to the real upstream
proxy_pass https://api.webservice.serverless.industries;
}
}
server {
server_name example.com;
listen 443 ssl http2;
listen [::]:443 ssl http2;
ssl_certificate /etc/ssl/http/bundle_example.com.cert;
ssl_certificate_key /etc/ssl/http/example.com.key;
location / {
proxy_cache examplecache;
proxy_cache_methods GET HEAD POST;
proxy_cache_lock on;
proxy_read_timeout 60s;
proxy_http_version 1.1;
proxy_redirect off;
proxy_cache_key $scheme$proxy_host$request_uri$is_args$args;
# prepare caching headers
proxy_hide_header X-Cache;
proxy_set_header X-Cache-TTL $http_x_cache_ttl;
add_header X-Cache $upstream_cache_status;
add_header X-Cache-TTL $http_x_cache_ttl;
# Forward to intermediate nginx server block
proxy_set_header Host api.webservice.serverless.industries;
proxy_pass https://127.0.0.1:7443;
}
}
```
Ablauf:
- Eingehendes Request auf example.com mit `X-Cache-TTL` header
- Weiterleitung an 127.0.0.1:7443
- Weiterleitung an api.webservice.serverless.industries
- Antwort mit Response und `X-Accel-Expires` header mit dem Inhalt von `X-Cache-TTL`
- example.com nutzt die Zeitangabe in Sekunde aus `X-Accel-Expires` zur Anlage des Cache
- Antwort an den Benutzer
## Hohes Missbrauchspotential
Man sollte sich ganz genau überlegen, ob man dieses Setup ungeschützt
im Internet betreibt. Macht ein User einen Fehler oder setzt gar falsche Werte aus Absicht,
kann dies zum Beispiel die Festplatte vollaufen lassen oder den Upstream unbrauchbar machen,
da Daten (zum Beispiel) für 100 Jahre gecached werden.
In meinem Fall läuft das Setup in einem geschützten Netzwerk und
im `proxy_cache_key` ist eine User ID enthalten. Das sorgt dafür, dass der
Cache immer nur für einen Benutzer gilt und somit nicht alle anderen Benutzer
beeinträchtigt.
---
author: christian
title: Deutsche Sonderzeichen auf US Tastaturen
language: german
tags: ['windows', 'keyboard']
---
Seit einiger Zeit besitze ich ein kleines Notebook mit einem
US Amerikanischen Tastatur Layout.
Um beim Schreiben von Texten dennoch Umalute nutzen zu können,
sollte man das Layout in den Windows Einstellungen auf
**English (United States - International Keyboard)** umzustellen.
Dies bietet mehr oder weniger komfortable Shortcuts:
{:.table .table-bordered}
| Zeichen | Shortcut |
|---|---|
| ü/Ü | " + u |
| ä/Ä | " + a |
| ö/Ö | " + o |
| ß | Ctrl + Alt + s |
| € | Ctrl + Alt + 5 |
Umstelen kann man die Tastatur in den Optionen der jeweiligen
"Preferred Language".