Én URL for kontoret og VPN? Hvorfor myten om tillatelseslisten svikter

Koble til tunnelen, åpne det samme bokmerket, og den tillatte siden svarer nøyaktig som den gjorde fra kontoret. Det er forutsetningen de fleste fjernaksesplaner stille hviler på, og den holder bare så lenge tre separate ting er sanne samtidig. Ingen av dem er en funksjon i VPN-klienten, og ingen DNS-post kan levere noen av dem. Når bokmerket feiler hjemme, gir nettleseren deg én generisk feil, enten årsaken er en manglende rute, en ikke-godkjent utgangsadresse eller en proxy som har erstattet kilden den rapporterer. Å behandle de tre som ett problem er måten en liten policyretting blir til en uke med å utvide tillatelseslister.

Designet som overlever møtet med et ekte kontornettverk er smalere enn forutsetningen: en eksplisitt beslutningstabell med tre rader, ett håndhevelsespunkt som ikke kan omgås, og en avvisningstest som beviser noe. Å demontere forutsetningen kommer først, fordi alt etterpå avhenger av å vite hvilket lag som fremstiller kilden feil.

Myten: å koble til er ikke å rute

En tunnel etableres, og klienten installerer ruter for et sett med prefikser. Det er alt tilkobling gjør. Om en urelatert HTTPS-forespørsel reiser gjennom tunnelen, og hvilken offentlig adresse den ser ut til å komme fra når den ankommer, er beslutninger andre komponenter tar senere: rutetabellen velger veien, og utgangen velger kilden.

Derfor skiller kontoret og kjøkkenbordet lag med samme bærbare maskin, samme nettleserprofil og samme bokmerke. På kontoret forlater forespørselen gjennom en vedlikeholdt offentlig adresse som nettstedets operatør har godtatt. Gjennom en full tunnel kan den forlate gjennom VPN-utgangen, som er en annen adresse og, til noen legger den til, en ikke-godkjent en. Gjennom en splittunnel kommer den kanskje ikke inn i tunnelen i det hele tatt. Bare to av disse tre veiene var noen gang en del av avtalen med nettstedets eier, og den tredje er ikke en feil som skal lappes med en ekstra allow-linje.

Tre forespørselstilstander, to godkjente utganger

Skriv ned matrisen før du rører en brannmur, fordi tabellen er designet og regelen bare er én implementasjon av det. Adressene nedenfor er dokumentasjonsområder; erstatt dem med dine egne vedlikeholdte verdier og oppbevar dem der nettstedets eier kan revidere dem.

Den midterste raden er der de fleste av disse planene bryter sammen. Det som teller er adressen håndhevelsesenheten ser, ikke den private adressen den bærbare maskinen har inne i tunnelen, og ikke dens LAN-adresse. En verdi som 10.8.0.6 betyr ingenting for et offentlig nettsted, og det gjør 192.168.1.44 heller ikke. En tunneladresse er en adresseringsdetalj for tunnelen, ikke en legitimasjon nettstedet kan kontrollere.

Hvis VPN-en din ikke kan levere en stabil, dokumentert utgang, har matrisen ingen gyldig midterste rad, og ingen mengde tillatelseslister finner opp en. De ærlige alternativene på det punktet er et privat nettsted nådd over eksplisitte private ruter, eller en identitetsbevisst tilgangsgateway foran applikasjonen. Begge har en annen kontrakt enn en offentlig tillatelsesliste, og begge er lettere å forklare for en revisor enn en liste som vokste til den tilfeldigvis virket.

Les kilden der beslutningen tas

Sett begrensningen på enheten som avslutter forespørselen, og bekreft at ingen alternativ opprinnelsesvei hopper over den. Nginx-tilgangsmodulen vurderer allow- og deny-direktivene i rekkefølge, første treff vinner, og regler som er arvet fra en omsluttende blokk gjelder fortsatt inne i location. En smal allow ved siden av en bred allow på samme sted betyr vanligvis at den brede bestemmer. Les hele den effektive konfigurasjonen for den location før du redigerer en eneste linje av 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;
    }
}

Bak en lastbalanserer eller omvendt proxy ser den regelen proxyen med mindre du sier noe annet til den. Gjenopprett bare kallerens adresse gjennom den støttede betrodde-proxy-mekanismen, med en eksplisitt liste over proxyadresser. Et forespørselshode som hevder en godkjent adresse er ikke bevis for at kalleren eier den, og på en offentlig lytter gjør et uvalidert videresendt hode tillatelseslisten til dekorasjon.

Kontroller så den andre adressefamilien. Et regelsett som bare dekker IPv4 er en ufullstendig beslutning for et vertsnavn som også svarer på AAAA, og en klient med fungerende IPv6 vil nå samme applikasjon via en vei du aldri har gjennomgått.

Splittunnel: forespørselen som aldri kommer inn

En splittunnel bærer bare prefiksene på listen sin. Interne kontorsubnett står vanligvis på den listen; et offentlig nettsted gjør det ikke. Nettleseren slår opp navnet, sammenligner den valgte adressen med rutetabellen og finner likevel den lokale standardgatewayen foran seg.

Så forespørselen kommer fra brukerens hjemmeforbindelse, blir avvist, og rapporten sier at VPN-en er ødelagt mens tunnelen gjør nøyaktig det den ble konfigurert til. To rettelser er legitime: rut den destinasjonen gjennom tunnelen og la den godkjente utgangen bære den, eller godta at nettstedet nås direkte og gi fjernbrukere en annen godkjent vei, for eksempel tilgangsgatewayen. Å utvide nettstedets offentlige tillatelsesliste til en hjemmeadresse tilfeldigvis er inkludert er ingen av delene, og det fjerner grensen designet skulle håndheve. De to første holder matrisen ærlig; den tredje sletter stille en rad fra den.

Bevis avvisningen, så gjenopprettingen

Test med en forespørsel som utøver den reelle beslutningen, fra en klient som står på hver rad i tabellen. En tilgjengelighetstest mot en eller annen urelatert adressevisende side beviser ingenting, fordi den destinasjonen kan følge en annen rute enn applikasjonen.

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 tilgangsloggen ved grensen med det tabellen forutsa. Senk så tunnelen og lag en ny forespørsel som skal avvises; en side som allerede er lastet, eller en forbindelse som allerede er åpen, tester ingenting som helst. Hvis ingen avvisning vises, er håndhevelsespunktet ikke der du tror.

Behold applikasjonsautentiseringen etter nettverkstilgang, fordi en kontorutgang og en VPN-utgang hver representerer mange mennesker, og ingen av dem identifiserer en person. Instruksjonen til brukerne forblir kort: reis den godkjente tunnelen, prøv så igjen. Det er dette som holder én URL praktisk mens kilderegelen forblir en beslutning og ikke en gjetning.