Én URL til kontoret og VPN? Hvorfor myten om tilladelseslisten fejler

Forbind tunnelen, åbn det samme bogmærke, og den tilladte side svarer præcis, som den gjorde fra kontoret. Det er den antagelse, de fleste fjernadgangsplaner stille hviler på, og den holder kun, så længe tre separate ting er sande på samme tid. Ingen af dem er en funktion i VPN-klienten, og ingen DNS-post kan levere nogen af dem. Når bogmærket fejler derhjemme, giver browseren dig én generisk fejl, uanset om årsagen er en manglende rute, en ikke-godkendt udgangsadresse eller en proxy, der har erstattet den kilde, den rapporterer. At behandle de tre som ét problem er måden, hvorpå en lille politikrettelse bliver til en uge med at udvide tilladelseslister.

Det design, der overlever mødet med et rigtigt kontornetværk, er snævrere end antagelsen: en eksplicit beslutningstabel med tre rækker, ét håndhævelsespunkt, der ikke kan omgås, og en afvisningstest, der beviser noget. At skille antagelsen ad kommer først, fordi alt derefter afhænger af at vide, hvilket lag der fremstiller kilden forkert.

Myten: at forbinde er ikke at route

En tunnel etableres, og klienten installerer ruter for et sæt præfikser. Det er alt, hvad forbindelsen gør. Om en uafhængig HTTPS-anmodning rejser gennem tunnelen, og hvilken offentlig adresse den ser ud til at komme fra, når den ankommer, er beslutninger, som andre komponenter træffer senere: routingtabellen vælger stien, og udgangen vælger kilden.

Derfor skilles kontoret og køkkenbordet med samme bærbare, samme browserprofil og samme bogmærke. På kontoret forlader anmodningen gennem en vedligeholdt offentlig adresse, som webstedets operatør har accepteret. Gennem en fuld tunnel kan den forlade gennem VPN-udgangen, som er en anden adresse og, indtil nogen tilføjer den, en ikke-godkendt. Gennem en splittunnel kommer den måske slet ikke ind i tunnelen. Kun to af disse tre stier var nogensinde en del af aftalen med webstedets ejer, og den tredje er ikke en fejl, der skal lappes med en ekstra allow-linje.

Tre anmodningstilstande, to godkendte udgange

Skriv matricen ned, før du rører en firewall, fordi tabellen er designet, og reglen kun er én implementering af det. Adresserne nedenfor er dokumentationsområder; erstat dem med dine egne vedligeholdte værdier, og opbevar dem et sted, hvor webstedets ejer kan revidere dem.

Den midterste række er der, hvor de fleste af disse planer brækker. Det, der tæller, er den adresse, håndhævelsesenheden ser, ikke den private adresse, den bærbare har inde i tunnelen, og ikke dens LAN-adresse. En værdi som 10.8.0.6 betyder intet for et offentligt websted, og det gør 192.168.1.44 heller ikke. En tunneladresse er en adresseringsdetalje for tunnelen, ikke en legitimation, som webstedet kan kontrollere.

Hvis din VPN ikke kan levere en stabil, dokumenteret udgang, har matricen ingen gyldig midterste række, og ingen mængde tilladelseslister opfinder en. De ærlige muligheder på det punkt er et privat websted nået over eksplicitte private ruter eller en identitetsbevidst adgangsgateway foran applikationen. Begge har en anden kontrakt end en offentlig tilladelsesliste, og begge er lettere at forklare en revisor end en liste, der voksede, indtil den tilfældigvis virkede.

Læs kilden, hvor beslutningen træffes

Sæt begrænsningen på den enhed, der afslutter anmodningen, og bekræft, at ingen alternativ oprindelsessti springer den over. Nginx-adgangsmodul evaluerer allow- og deny-direktiver i rækkefølge, første match vinder, og regler, der er nedarvet fra en omsluttende blok, gælder stadig inde i location. En smal allow ved siden af en bred allow samme sted betyder normalt, at den brede bestemmer. Læs hele den effektive konfiguration for den location, før du redigerer en enkelt linje i den.

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;
    }
}

Bag en load balancer eller omvendt proxy ser den regel proxien, medmindre du fortæller den andet. Gendan kun kalderens adresse gennem den understøttede betroede-proxy-mekanisme, med en eksplicit liste over proxyadresser. Et anmodningshoved, der hævder en godkendt adresse, er ikke bevis for, at kalderen ejer den, og på en offentlig lytter gør et uvalideret videresendt hoved tilladelseslisten til dekoration.

Kontrollér så den anden adressefamilie. Et regelsæt, der kun dækker IPv4, er en ufuldstændig beslutning for et værtsnavn, der også svarer på AAAA, og en klient med fungerende IPv6 vil nå den samme applikation ad en sti, du aldrig har gennemgået.

Splittunnel: anmodningen, der aldrig kommer ind

En splittunnel bærer kun de præfikser, der står på dens liste. Interne kontorsubnet optræder normalt på den liste; et offentligt websted gør ikke. Browseren opløser navnet, sammenligner den valgte adresse med routingtabellen og finder alligevel den lokale standardgateway foran den.

Så anmodningen kommer fra brugerens hjemmeforbindelse, bliver afvist, og rapporten siger, at VPN’en er i stykker, mens tunnelen gør præcis det, den blev konfigureret til. To rettelser er legitime: rute den destination gennem tunnelen og lad den godkendte udgang bære den, eller accepter, at webstedet nås direkte, og giv fjernbrugere en anden godkendt sti, for eksempel adgangsgatewayen. At udvide webstedets offentlige tilladelsesliste, indtil en hjemmeadresse tilfældigvis er med, er ingen af delene, og det fjerner den grænse, som designet skulle håndhæve. De to første holder matricen ærlig; den tredje sletter stille en række i den.

Bevis afvisningen, så genopretningen

Test med en anmodning, der udøver den reelle beslutning, fra en klient, der står på hver række i tabellen. En tilgængelighedstest mod en eller anden uafhængig adressevisende side beviser intet, fordi den destination kan følge en anden rute end applikationen.

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/'

Sammenlign grænsens adgangslog med det, tabellen forudsagde. Sæt derefter tunnelen ned, og lav en ny anmodning, der bør afvises; en side, der allerede er indlæst, eller en forbindelse, der allerede er åben, tester intet som helst. Hvis der ikke vises nogen afvisning, er håndhævelsespunktet ikke der, hvor du tror.

Behold applikationsgodkendelsen efter netværksadgang, fordi en kontorudgang og en VPN-udgang hver repræsenterer mange mennesker, og ingen af dem identificerer en person. Instruktionen til brugerne forbliver kort: rejs den godkendte tunnel, prøv igen. Det er det, der gør én URL bekvem, mens kilderegelen forbliver en beslutning og ikke et gæt.