Kategorie-Archiv: Allgemein

Problem

Man möchte einen Webserver hinter einem IIS als „Frontend“ Reverse Proxy via ARR (Application Request Routing) betrieben und dem IIS das SSL-Offloading überlassen.

Der reverse Proxy ist schnell eingerichtet, aber wie vermeidet man, das ein ACME-Tool (beispielsweise win-acme) an der Validierung des Zertifikates scheitert, weil der IIS die Requests an /.well-known/acme-challenge/* ebenfalls an den Webserver weiterleitet?

Lösung

Man verwendet verschiedene Regeln um das zu verhindern. Entweder erstellt man diese im wundervollen IIIS GUI oder bearbeitet die zugehörige web.config:

<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <clear />


<!-- Letsencrypt-Ausnahme -->
                <rule name="LetsEncryptException" stopProcessing="true">
                    <match url=".well-known/acme-challenge/*" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
                    <action type="None" />
                </rule>


<!-- Redirect auf HTTPS -->
                <rule name="Redirect-HTTPS" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                        <add input="{HTTPS}" pattern="^OFF$" />
                    </conditions>
                    <action type="Redirect" url="https://DEINEDOMAIN.COM/{R:1}" appendQueryString="false" redirectType="Found" />
                </rule>


<!-- Redirect root "/" in Verzeichnis (oft hilfreich bei Tomcat Apps) -->
		<rule name="redirect-to-subdir" stopProcessing="true">
			<match url="^$" />
			<action type="Redirect" url="https://DEINEDOMAIN.COM/DEINVERZEICHNIS/WHATEVER" />
		</rule>


<!-- Reverse Proxy -->
                <rule name="ReverseProxy" stopProcessing="false">
                    <match url="(.*)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
                    <action type="Rewrite" url="http://INTERNERSERVER:8059/{R:1}" />
                </rule>


            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Problem

Verwendet man mehrere OneDrive-Konten auf einem Computer, kommt es gelegentlich zu diesem Fehler, wenn man Dateien aus dem „zweiten“ OneDrive Ordner öffnet. Die Meldung kommt immer, unabhängig ob man die Dateien „on demand“ nutzen möchte oder vollständig synchronisiert hat.

Ihre Änderungen können nicht hochgeladen oder heruntergeladen werden, weil ihre zwischengespeicherten Anmeldeinformationen abgelaufen sind.

Wenn man sich dann anzumelden versucht, wie von Excel so prominent vorgeschlagen, erhält man die Fehlermeldung:

Leider ist an diesem Computer bereits ein anderes Konto aus Ihrer Organisation angemeldet.

Lösung

Das Problem sind die Office-Apps, die direkt versuchen mit dem angemeldeten Benutzer in das „fremde“ OneDrive zu schreiben. Das schlägt natürlich fehl, aber Office ignoriert hier scheinbar (äußerst penetrant) die erfolgte und korrekte Einrichtung als zweites OneDrive.

Glücklicherweise kann man dem OneDrive Client abgewöhnen, die Office-Apps zu konfigurieren. Die Option ist nur etwas seltsam benannt.

OneDrive-Symbol > Einstellungen > Office > „Office-Dateien, die ich öffne, mit Office-Anwendungen synchronisieren“ abschalten

Und schon funktrioniert der Zugriff wieder fehlerfrei – es ist nicht einmal ein Neustart notwendig (außer von den Office-Apps).

Allerdings gehen durch diese Umstellung die synchronen Online-Features verloren, wie die gleichzeitige Bearbeitung einer Datei durch mehrere Benutzer oder das automatische Online-Speichern.

Das VPN mit einer Fritz!Box aufzubauen war irritierend umständlich. Die Fritz!Box kann überraschend viel, zeigt das nur leider nicht und ist zumindest in Richtung VPN-Settings nicht wirklich gut dokumentiert. Zugegeben, die Box ist kein „Unternehmensrouter“, aber in Corona-Homeoffice Zeiten muss man nehmen was man kriegen kann 🙂 Auf die Details was und warum ehe ich nicht ein, das hier ist nur die „working config“, wie von uns gewohnt.

In diesem Fall: Sonicwall NSA 3650 und eine aktuelle Fritz!Box. Welche genau weiss ich nicht, aber das ist in weiten Teilena auch egal.

Wichtig: Keines der zu verbindenden Netze darf identisch oder ein Subnetz des anderen sein. Die Fritzbox mag sowas nicht routen und für ein Homeoffice dann noch NAT-Pools einrichten ist … übertrieben.

• Unternehmen: 192.168.0.0 /16
• Homeoffice: 10.0.178.0 /24

Sonicwall Seite

Ich nutze der Einfachheit halber eine VPN-Policy, kein Tunnelinterface. Das schöne daran ist, das der Tunnel seine SA’s sofort in die Routingtabelle einträgt, wenn also der Tunnel steht direkt das IP-Netzwerk verfügbar ist.

Ich gehe davon aus, das alle beteiligten Netzwerkobjekte bereits als solche angelegt sind.

VPN Policy auf der Sonicwall hinzufügen

Manage > VPN > Base Settings > Add

• Security Policy
  • Policy-Type: Site to Site
  • Authentication Method: IKE using Preshared Secret
  • Name: FBox-VPN-42
  • Psec Primary Gateway Name or Address: <IP/DNS der Homeoffice FBox>
• IKE Authentication
  • Shared Secret: <Supergeheimeskennwort>
  • Local IKE ID: Domain Name : <IP/FQDN der Sonicwall>
  • Peer IKE ID: Domain Name : <IP/FQDN der Fritz!Box>

• Network
  • Local Networks
    • Choose local network from list: <Objektgruppe der/des Unternehmens-Netzwerke>
  • Remote Networks
    • Choose destination network from list: <Objektgruppe des Homeoffice-Netzes>

• Proposals
  • IKE (Phase 1) Proposal
    • Exchange: Aggressive Mode
    • DH Group: Group 2
    • Encryption: AES-256
    • Authentication: SHA1
    • Life Time (seconds): 28800
  • Ipsec (Phase 2) Proposal
    • Protocol: ESP
    • Encryption: AES-256
    • Authentication: SHA1
    • Enable Perfect Forward Secrecy Einschalten (!)
    • DH Group: Group 2
    • Life Time (seconds): 3600

FRITZ!Box Seite

Man nutze nicht den „Firmen“ Assistenten, sondern lade die Konfiguration vie „Datei importieren“ hoch. Das geht unter Internet > Freigaben > VPN.

Eine laufende CFG Configfile sieht so aus:

 vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "Tunnel to Northkorea";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "<IP/FQDN Sonicwall>";
                localid {
                        fqdn = "<IP/FQDN FRITZ!Box>";
                }
                remoteid {
                        fqdn = "<IP/FQDN Sonicwall>";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "<Supergeheimeskennwort>";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = <NetzID FritzBox-Netzwerk>;
                                mask = <Subnetzmaske FritzBox-Netzwerk>;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = <NetzID Unternehmensnetzwerk>;
                                mask = <Subnetzmaske Unternehmensnetzwerk>;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist =    "permit ip any <NetzID FritzBox-Netzwerk> <Subnetzmaske FritzBox-Netzwerk>",
                                "permit ip any <NetzID Unternehmensnetzwerk> <Subnetzmaske Unternehmensnetzwerk>";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
} 

Problem

Es kommt mal vor, das Zertifikate ablaufen. Tausch der Admins das Zertifikat dann auch, anstatt ein bestehendes zu verlängern, passiert es gerne das Edge/Chrome/Firefox die Verbindung verweigern.

Lösung

HSTS (HTTP Strict Transport Security) ist ein krasser Schutz für HTTPS-Verbindungen. Dabei wird dem Browser der HTTP Response Header „Strict-Transport-Security“ vom Server gesendet. Dies veranlasst den Browser zukünftig nur verschlüsselte Verbindungen zu dieser Domain aufzubauen. An sich eine nette Erfindung die „Fallback man in the middle“ Attacken verhindert.

Die meisten Browser speichern zusätzlich zu dem Flag für die Domain(s) auch noch den Thumprint der Certifikates. Ändert sich der Fingerabdruck, läuft man in diesen unumgänglichen Fehler.

Firefox

1. Alle Tabs und Fenster schließen, bis auf eins
2. Bibliothek > Chronik > gesammte Chronik anzeigen
3. Nach der betroffenen Seitenadresse suchen
4. Rechte MT und „Gesamte Webseite vergessen“ wählen
5. Einen Moment warten, Firefoxy neu starten, geht.

Chrome

Chrome ist leider etwas umständlicher zu bedienen:

1. Öffne chrome://net-internals/#hsts
2. Unter „Query HSTS/PKP domain“ nach der Domain suchen. Achtung, das ist FQDN-Sensitiv. Wenn die Domain auftaucht …
3. Ganz unten unter „Delete domain security policies“ den FQDN eintragen
4. „Delete“ löscht die zugehörigen Einträge
5. Chrome neu starten, fertig

Problem

Es tritt „auf einmal“ der folgende Fehler auf:

Hash-Summe stimmt nicht überein
......
Es wurden 42,42 MB in 42 s geholt (42 MB/s).
Paketlisten werden gelesen... Fertig
E: Fehlschlag beim Holen von ..... Hash-Summe stimmt nicht überein
E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.

Lösung

Sofern die Eintröge in der /etc/apt/sources.list korrekt sind, kann es nur apt’s cache sein. Aufräumen hilft in der Regel:

sudo apt-get clean
sudo rm -R /var/lib/apt/lists
sudo mkdir -p /var/lib/apt/lists/partial
sudo apt-get update

Ursache

Die möglichen Ursache sind zwar techinsch vielfältig, lassen sich aber in aller Regel auf eine dieser vier Möglichkeiten eingrenzen:

1. APT hat andere Metadaten als der server. In den meisten Fällen ist das wegen der Verwendundung von TLS eher unwahrscheinlich, aber möglich.
2. Der Metadatensatz stimmen aufgrund eines Fehlers beim kopieren/extrahieren/widerherstellen nicht (mehr) überein.
3. Das Repository wurde von APT genau dann aktualisiert, wenn APT ein Update ausführen wollte, oder APT hat eine veraltete Metadatei zwischengespeichert (die wegen dieses Zugriffskonfliktes nicht entfernt werden konnt).
4. Die Debian repositories wurden gehackt und der lokale, korrekte, Hash passt nicht zur gehackten Version (unwarscheinlich)