Eine URL für Büro und VPN? Warum der Mythos der Allowlist scheitert

Stellen Sie den Tunnel her, öffnen Sie dasselbe Lesezeichen, und die freigegebene Website antwortet genau so, wie sie es aus dem Büro tat. Das ist die Annahme, auf der die meisten Fernzugriffspläne still ruhen, und sie gilt nur, solange drei getrennte Dinge gleichzeitig wahr bleiben. Keines davon ist eine Funktion des VPN-Clients, und kein DNS-Eintrag kann eines davon liefern. Wenn das Lesezeichen zu Hause scheitert, gibt Ihnen der Browser einen generischen Fehler, ob die Ursache nun eine fehlende Route, eine nicht freigegebene Exit-Adresse oder ein Proxy ist, der die gemeldete Quelle ersetzt hat. Diese drei als ein einziges Problem zu behandeln, ist der Weg, auf dem aus einer kleinen Richtlinienkorrektur eine Woche des Erweiterns von Allowlists wird.

Das Design, das den Kontakt mit einem echten Büronetz übersteht, ist enger als die Annahme: eine ausdrückliche Entscheidungstabelle mit drei Zeilen, ein Durchsetzungspunkt, der nicht umgangen werden kann, und ein Ablehnungstest, der etwas beweist. Das Zerlegen der Annahme kommt zuerst, weil alles danach davon abhängt zu wissen, welche Schicht die Quelle falsch darstellt.

Der Mythos: Verbinden ist nicht Routing

Ein Tunnel wird aufgebaut, und der Client installiert Routen für eine Menge von Präfixen. Das ist alles, was Verbinden tut. Ob eine unabhängige HTTPS-Anfrage durch den Tunnel reist und von welcher öffentlichen Adresse sie beim Ankommen zu stammen scheint, sind Entscheidungen, die später andere Komponenten treffen: die Routing-Tabelle wählt den Pfad, und der Exit wählt die Quelle.

Deshalb laufen Büro und Küchentisch mit demselben Laptop, demselben Browserprofil und demselben Lesezeichen auseinander. Im Büro verlässt die Anfrage über eine gepflegte öffentliche Adresse, der der Betreiber der Website zugestimmt hat. Durch einen vollen Tunnel kann sie über den VPN-Egress verlassen, eine andere Adresse und, bis jemand sie hinzufügt, eine nicht freigegebene. Durch einen Split-Tunnel betritt sie den Tunnel möglicherweise gar nicht. Nur zwei dieser drei Pfade waren je Teil der Vereinbarung mit dem Website-Eigentümer, und der dritte ist kein Fehler, der mit einem zusätzlichen Allow-Eintrag zu flicken ist.

Drei Anfragezustände, zwei freigegebene Exits

Schreiben Sie die Matrix auf, bevor Sie eine Firewall anfassen, denn die Tabelle ist das Design und die Regel nur eine Umsetzung davon. Die Adressen unten sind Dokumentationsbereiche; ersetzen Sie sie durch Ihre eigenen gepflegten Werte und bewahren Sie sie dort auf, wo der Website-Eigentümer sie prüfen kann.

Die mittlere Zeile ist der Punkt, an dem die meisten dieser Pläne brechen. Entscheidend ist die Adresse, die das durchsetzende Gerät sieht, nicht die private Adresse, die der Laptop im Tunnel hält, und nicht seine LAN-Adresse. Ein Wert wie 10.8.0.6 bedeutet einer öffentlichen Website nichts, und 192.168.1.44 ebenso wenig. Eine Tunneladresse ist ein Adressierungsdetail des Tunnels, kein Nachweis, den die Website prüfen kann.

Kann Ihr VPN keinen stabilen, dokumentierten Egress bereitstellen, hat die Matrix keine gültige mittlere Zeile, und keine Menge an Allowlists erfindet eine. Die ehrlichen Optionen sind dann eine private Website, die über ausdrückliche private Routen erreicht wird, oder ein identitätsbewusstes Zugangs-Gateway vor der Anwendung. Beide haben einen anderen Vertrag als eine öffentliche Allowlist, und beide lassen sich einem Prüfer leichter erklären als eine Liste, die wuchs, bis sie zufällig funktionierte.

Lesen Sie die Quelle dort, wo die Entscheidung fällt

Legen Sie die Beschränkung auf das Gerät, das die Anfrage beendet, und stellen Sie sicher, dass kein alternativer Herkunftspfad sie umgeht. Das Nginx-Zugriffsmodul wertet allow- und deny-Direktiven der Reihe nach aus, der erste Treffer gewinnt, und aus einem umschließenden Block geerbte Regeln gelten weiterhin innerhalb von location. Ein enges allow neben einem weiten allow an derselben Stelle bedeutet meist, dass das weite entscheidet. Lesen Sie die gesamte wirksame Konfiguration für dieses location, bevor Sie auch nur eine Zeile davon ändern.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Hinter einem Load Balancer oder Reverse Proxy sieht diese Regel den Proxy, sofern Sie ihr nichts anderes sagen. Stellen Sie die Adresse des Aufrufers nur über den unterstützten Mechanismus für vertrauenswürdige Proxys wieder her, mit einer ausdrücklichen Liste von Proxy-Adressen. Ein Anfrage-Header, der eine freigegebene Adresse behauptet, ist kein Beweis, dass der Aufrufer sie besitzt, und an einem öffentlichen Listener macht ein ungeprüfter weitergeleiteter Header die Allowlist zur Dekoration.

Prüfen Sie dann die andere Adressfamilie. Ein Regelsatz, der nur IPv4 abdeckt, ist eine unvollständige Entscheidung für einen Hostnamen, der auch auf AAAA antwortet, und ein Client mit funktionierendem IPv6 erreicht dieselbe Anwendung über einen Pfad, den Sie nie überprüft haben.

Split-Tunnel: die Anfrage, die nie hineinkommt

Ein Split-Tunnel führt nur die Präfixe auf seiner Liste. Interne Büro-Subnetze stehen meist auf dieser Liste; eine öffentliche Website nicht. Der Browser löst den Namen auf, vergleicht die gewählte Adresse mit der Routing-Tabelle und findet trotzdem das lokale Standard-Gateway davor.

So kommt die Anfrage über die Heimverbindung des Nutzers, wird abgelehnt, und der Bericht liest sich, als sei das VPN kaputt, während der Tunnel genau das tut, wofür er konfiguriert wurde. Zwei Korrekturen sind legitim: Leiten Sie dieses Ziel durch den Tunnel und lassen Sie den freigegebenen Egress es tragen, oder akzeptieren Sie, dass die Website direkt erreicht wird, und geben Sie Fernnutzern einen anderen freigegebenen Pfad, etwa das Zugangs-Gateway. Die öffentliche Allowlist der Website zu erweitern, bis zufällig eine Heimadresse enthalten ist, ist keines von beidem, und es entfernt die Grenze, die das Design durchsetzen sollte. Die ersten beiden halten die Matrix ehrlich; die dritte löscht still eine Zeile daraus.

Beweisen Sie die Ablehnung, dann die Erholung

Testen Sie mit einer Anfrage, die die echte Entscheidung ausübt, von einem Client auf jeder Zeile der Tabelle. Eine Erreichbarkeitsprüfung gegen irgendeine unabhängige adressanzeigende Seite beweist nichts, weil dieses Ziel einer anderen Route folgen kann als die Anwendung.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Vergleichen Sie den Zugriffsdatensatz an der Grenze mit dem, was die Tabelle vorhergesagt hat. Nehmen Sie dann den Tunnel herunter und stellen Sie eine neue Anfrage, die abgelehnt werden sollte; eine bereits geladene Seite oder eine bereits offene Verbindung testet gar nichts. Erscheint keine Ablehnung, liegt der Durchsetzungspunkt nicht dort, wo Sie ihn vermuten.

Behalten Sie die Anwendungsauthentifizierung nach der Netzaufnahme bei, denn ein Büro-Exit und ein VPN-Egress stehen jeweils für viele Menschen, und keiner identifiziert eine Einzelperson. Die Anweisung für Nutzer bleibt kurz: freigegebenen Tunnel hochfahren, dann erneut versuchen. Das hält eine URL bequem, während die Quellenregel eine Entscheidung bleibt und keine Vermutung.