Éin URL for kontoret og VPN? Kvifor myten om tillatingslista sviktar

Kopla til tunnelen, opne det same bokmerket, og den tillatne sida svarar nøyaktig som ho gjorde frå kontoret. Det er føresetnaden dei fleste fjernåkomstplanar stille kviler på, og han held berre så lenge tre skilde ting er sanne samstundes. Ingen av dei er ein funksjon i VPN-klienten, og ingen DNS-post kan levera nokon av dei. Når bokmerket sviktar heime, gir nettlesaren deg éin generisk feil, anten årsaka er ei manglande rute, ei ikkje-godkjend utgangsadresse eller ein proxy som har erstatta kjelda han rapporterer. Å handsame dei tre som eitt problem er måten ei lita policyretting blir ei veke med å utvide tillatingslister.

Designet som overlever møtet med eit ekte kontornettverk er smalare enn føresetnaden: ein eksplisitt avgjerdstabell med tre radar, eitt handhevingspunkt som ikkje kan omgåast, og ein avvisingstest som beviser noko. Å demontere føresetnaden kjem først, fordi alt etterpå avheng av å vita kva lag som framstiller kjelda feil.

Myten: å kopla til er ikkje å rute

Ein tunnel blir etablert, og klienten installerer ruter for eit sett med prefiks. Det er alt tilkopling gjer. Om ein urelatert HTTPS-førespurnad reiser gjennom tunnelen, og kva offentleg adresse han ser ut til å koma frå når han kjem, er avgjerder andre komponentar tek seinare: rutetabellen vel vegen, og utgangen vel kjelda.

Difor skil kontoret og kjøkenbordet lag med same berebøre maskin, same nettlesarprofil og same bokmerke. På kontoret forlèt førespurnaden gjennom ei vedlikehalden offentleg adresse som nettstadoperatøren har godteke. Gjennom ein full tunnel kan han forlata gjennom VPN-utgangen, som er ei anna adresse og, til nokon legg ho til, ei ikkje-godkjend ei. Gjennom ein splittunnel kjem han kanskje ikkje inn i tunnelen i det heile. Berre to av desse tre vegane var nokon gong ein del av avtalen med eigaren av nettstaden, og den tredje er ikkje ein feil som skal lappast med ei ekstra allow-linje.

Tre førespurnadstilstandar, to godkjende utgangar

Skriv ned matrisa før du rører ein brannmur, fordi tabellen er designet og regelen berre er éin implementasjon av det. Adressene nedanfor er dokumentasjonsområde; byt dei ut med dine eigne vedlikehaldne verdiar og oppbevar dei der eigaren av nettstaden kan revidere dei.

Den midtre rada er der dei fleste av desse planane bryt saman. Det som tel er adressa handhevingsseininga ser, ikkje den private adressa den berebøre maskina har inne i tunnelen, og ikkje LAN-adressa hennar. Ein verdi som 10.8.0.6 tyder ingenting for ein offentleg nettstad, og det gjer 192.168.1.44 heller ikkje. Ei tunneladresse er ein adresseringsdetalj for tunnelen, ikkje ein legitimasjon nettstaden kan kontrollere.

Viss VPN-en din ikkje kan levera ein stabil, dokumentert utgang, har matrisa inga gyldig midtre rad, og inga mengd tillatingslister finn opp ei. Dei ærlege alternativa på det punktet er ein privat nettstad nådd over eksplisitte private ruter, eller ein identitetsmedviten åkomstport foran applikasjonen. Begge har ein annan kontrakt enn ei offentleg tillatingsliste, og begge er lettare å forklare for ein revisor enn ei liste som voks til ho tilfeldigvis verka.

Les kjelda der avgjerda blir teken

Set avgrensinga på eininga som avsluttar førespurnaden, og stadfest at ingen alternativ opphavsveg hoppar over ho. Nginx-åkomstmodulen vurderer allow- og deny-direktiva i rekkjefølgje, første treff vinn, og reglar som er arva frå ein omsluttande blokk gjeld framleis inne i location. Ein smal allow ved sida av ein brei allow på same stad tyder vanlegvis at den breie avgjer. Les heile den effektive konfigurasjonen for den location før du redigerer ein einaste linje av han.

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 ein lastbalansar eller ein omvend proxy ser den regelen proxyen med mindre du seier noko anna til han. Gjenopprett berre adressa til kallaren gjennom den støtta betrudde-proxy-mekanismen, med ei eksplisitt liste over proxyadresser. Eit førespurnadshovud som hevdar ei godkjend adresse er ikkje prov for at kallaren eig ho, og på ein offentleg lyttar gjer eit uvalidert vidaresendt hovud tillatingslista til dekorasjon.

Kontroller så den andre adressefamilien. Eit regelsett som berre dekkjer IPv4 er ei ufullstendig avgjerd for eit vertsnamn som også svarar på AAAA, og ein klient med fungerande IPv6 vil nå same applikasjonen via ein veg du aldri har gjennomgått.

Splittunnel: førespurnaden som aldri kjem inn

Ein splittunnel ber berre prefiksa på lista si. Interne kontorsubnett står vanlegvis på den lista; ein offentleg nettstad gjer det ikkje. Nettlesaren slår opp namnet, samanliknar den valde adressa med rutetabellen og finn likevel den lokale standardporten foran seg.

Så kjem førespurnaden frå heimetilkoplinga til brukaren, blir avvist, og rapporten seier at VPN-en er øydelagd medan tunnelen gjer nøyaktig det han vart konfigurert til. To rettingar er legitime: rut den destinasjonen gjennom tunnelen og lat den godkjende utgangen bera han, eller godta at nettstaden blir nådd direkte og gi fjernbrukarar ein annan godkjend veg, til dømes åkomstporten. Å utvide den offentlege tillatingslista til nettstaden til ei heimeadresse tilfeldigvis er med er ingen av delane, og det fjernar grensa designet skulle handheve. Dei to første held matrisa ærleg; den tredje slettar stille ei rad frå ho.

Bevis avvisinga, så gjenopprettinga

Test med ein førespurnad som utøver den reelle avgjerda, frå ein klient som står på kvar rad i tabellen. Ein tilgjengelegheitstest mot ei eller anna urelatert adressevisande side beviser ingenting, fordi den destinasjonen kan følgje ein annan veg 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/'

Samanlikn åkomstloggen ved grensa med det tabellen spådde. Senk så tunnelen og lag ein ny førespurnad som skal avvisast; ei side som allereie er lasta, eller ei tilkopling som allereie er open, testar ingenting som helst. Viss inga avvising dukkar opp, er handhevingspunktet ikkje der du trur.

Hald på applikasjonsautentiseringa etter nettverkstilgang, fordi ein kontorutgang og ein VPN-utgang kvar representerer mange menneske, og ingen av dei identifiserer ein person. Instruksen til brukarane blir kort: reis den godkjende tunnelen, prøv så igjen. Det er dette som held éin URL praktisk medan kjelda-regelen blir verande ei avgjerd og ikkje ei gjetting.