Een URL vir kantoor en VPN? Hoekom die toelatingslys-mite misluk

Koppel die tonnel, maak dieselfde boekmerk oop, en die toegelate werf antwoord presies soos dit van die kantoor af gedoen het. Dit is die aanname waarop die meeste afstandtoegangplanne stilweg rus, en dit hou net stand terwyl drie afsonderlike dinge gelyktydig waar bly. Nie een daarvan is ’n kenmerk van die VPN-kliënt nie, en geen DNS-rekord kan enige een daarvan verskaf nie. Wanneer die boekmerk by die huis misluk, gee die blaaier vir jou een generiese fout, of die oorsaak ’n ontbrekende roete, ’n nie-goedgekeurde uitgangadres of ’n proxy is wat die bron wat dit rapporteer vervang het. Om daardie drie as ’n enkele probleem te behandel, is hoe ’n klein beleidsregstelling in ’n week se verbreding van toelatingslyste verander.

Die ontwerp wat kontak met ’n werklike kantoor-netwerk oorleef, is smaller as die aanname: ’n eksplisiete beslissingstabel met drie rye, een handhawingspunt wat nie omseil kan word nie, en ’n weieringstoets wat iets bewys. Die afbreek van die aanname kom eerste, want alles daarna hang daarvan af om te weet watter laag die bron verkeerd voorstel.

Die mite: koppel is nie roete nie

’n Tonnel word opgerig, en die kliënt installeer roetes vir een of ander stel voorvoegsels. Dit is die geheel van wat koppel doen. Of ’n onverwante HTTPS-versoek deur die tonnel reis, en watter openbare adres dit blyk te hê wanneer dit aankom, is besluite wat later deur ander komponente geneem word: die roetetabel kies die pad, en die uitgang kies die bron.

Dit is waarom die kantoor en die kombuistafel met dieselfde skootrekenaar, dieselfde blaaierprofiel en dieselfde boekmerk uitmekaar loop. In die kantoor verlaat die versoek deur ’n onderhoue openbare adres wat die werfoperateur goedgekeur het. Deur ’n volle tonnel kan dit deur die VPN-uitgang verlaat, wat ’n ander adres is en, totdat iemand dit byvoeg, ’n nie-goedgekeurde een. Deur ’n gesplete tonnel mag dit glad nie die tonnel binnegaan nie. Slegs twee van daardie drie paaie was ooit deel van die ooreenkoms met die werf-eienaar, en die derde een is nie ’n fout wat met ’n ekstra toelatingsinsetsel gepleister moet word nie.

Drie versoektoestande, twee goedgekeurde uitgange

Skryf die matriks neer voordat jy ’n vuurmuur aanraak, want die tabel is die ontwerp en die reël is net een implementering daarvan. Adresse hieronder is dokumentasie-reekse; vervang dit met jou eie onderhoue waardes en hou hulle iewers waar die werf-eienaar dit kan oudit.

Die middelste ry is waar die meeste van hierdie planne breek. Wat tel, is die adres wat die handhawingstoestel sien, nie die private adres wat die skootrekenaar binne die tonnel hou nie en nie sy LAN-adres nie. ’n Waarde soos 10.8.0.6 beteken niks vir ’n openbare werf nie, en 192.168.1.44 ook nie. ’n Tonneladres is ’n adresseringsbesonderheid van die tonnel, nie ’n geloofsbrief wat die werf kan kontroleer nie.

As jou VPN nie ’n stabiele, gedokumenteerde uitgang kan verskaf nie, het die matriks geen geldige middelste ry nie en geen hoeveelheid toelatingslys sal een uitdink nie. Die eerlike opsies op daardie punt is ’n private werf wat oor eksplisiete private roetes bereik word, of ’n identiteitsbewuste toegangsportaal voor die toepassing. Albei het ’n ander kontrak as ’n openbare toelatingslys, en albei is makliker om aan ’n ouditeur te verduidelik as ’n lys wat gegroei het totdat dit toevallig gewerk het.

Lees die bron waar die besluit geneem word

Plaas die beperking op die toestel wat die versoek beëindig, en bevestig dat geen alternatiewe oorsprongroete dit oorslaan nie. Nginx-toegangsmodule evalueer allow- en deny-opdragte in volgorde, die eerste passing wen, en reëls wat van ’n omliggende blok geërf word, geld steeds binne die location. ’n Smal allow langs ’n breë allow op dieselfde plek beteken gewoonlik dat die breë een besluit. Lees die hele effektiewe konfigurasie vir daardie location voordat jy ’n enkele reël daarvan wysig.

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

Agter ’n lasbalanseerder of omgekeerde proxy sien daardie reël die proxy, tensy jy dit anders sê. Herstel die oproeper se adres slegs deur die ondersteunde vertroude-proxy-meganisme, met ’n eksplisiete lys proxy-adresse. ’n Versoekkop wat ’n goedgekeurde adres beweer, is nie bewys dat die oproeper dit besit nie, en op ’n openbare luisteraar maak ’n ongevalideerde doorgestuurde kop die toelatingslys tot versiering.

Kontroleer dan die ander adresfamilie. ’n Reëlstel wat net IPv4 dek, is ’n onvolledige besluit vir ’n gasheernaam wat ook op AAAA antwoord, en ’n kliënt met werkende IPv6 sal dieselfde toepassing bereik via ’n pad wat jy nooit hersien het nie.

Gesplete tonnel: die versoek wat nooit ingaan nie

’n Gesplete tonnel dra slegs die voorvoegsels op sy lys. Interne kantoor-subnette maak gewoonlik daardie lys; ’n openbare webwerf nie. Die blaaier los die naam op, vergelyk die gekose adres met die roetetabel, en vind steeds die plaaslike verstekpoort voor dit.

So die versoek kom van die gebruiker se tuisverbinding, word geweier, en die verslag lui dat die VPN stukkend is terwyl die tonnel presies doen waarvoor dit opgestel is. Twee regstellings is wettig: lei daardie bestemming deur die tonnel en laat die goedgekeurde uitgang dit dra, of aanvaar dat die werf direk bereik word en gee afstandgebruikers ’n ander goedgekeurde pad soos die toegangsportaal. Om die werf se openbare toelatingslys te verbreed totdat ’n tuisadres toevallig ingesluit is, is nie een van die twee nie, en dit verwyder die grens wat die ontwerp moes handhaaf. Die eerste twee hou die matriks eerlik; die derde skrap stilweg ’n ry daaruit.

Bewys die weiering, dan die herstel

Toets met ’n versoek wat die werklike besluit uitoefen, vanaf ’n kliënt wat op elke ry van die tabel staan. ’n Bereikbaarheidstoets teen een of ander onverwante adresrapporteringsbladsy bewys niks, want daardie bestemming volg dalk ’n ander roete as die toepassing.

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

Vergelyk die grens se toegangsrekord met wat die tabel voorspel het. Bring dan die tonnel af en maak ’n nuwe versoek wat geweier behoort te word; ’n bladsy wat reeds gelaai is, of ’n verbinding wat reeds oop is, toets glad niks. As geen weiering verskyn nie, is die handhawingspunt nie waar jy dink dit is nie.

Hou toepassing-verifikasie ná netwerktoelating, want ’n kantooruitgang en ’n VPN-uitgang staan elk vir baie mense en nie een identifiseer ’n individu nie. Die instruksie aan gebruikers bly kort: bring die goedgekeurde tonnel op, probeer dan weer. Dit is wat een URL gerieflik hou terwyl die bronreël ’n besluit bly in plaas van ’n raaiskoot.