Yksi URL toimistolle ja VPN:lle? Miksi sallittujen luettelon myytti kaatuu

Yhdistä tunneli, avaa sama kirjanmerkki, ja sallittu sivusto vastaa täsmälleen kuten toimistosta. Tämä on se oletus, jonka varassa useimmat etäkäyttösuunnitelmat hiljaa lepäävät, ja se pitää vain niin kauan kuin kolme erillistä asiaa on samanaikaisesti totta. Mikään niistä ei ole VPN-asiakasohjelman ominaisuus, eikä mikään DNS-tietue voi tarjota yhtäkään niistä. Kun kirjanmerkki epäonnistuu kotona, selain antaa sinulle yhden yleisen virheen, olipa syynä puuttuva reitti, hyväksymätön lähtöosoite tai välityspalvelin, joka korvasi ilmoittamansa lähteen. Näiden kolmen kohteleminen yhtenä ongelmana on se tapa, jolla pieni käytäntökorjaus muuttuu viikoksi sallittujen luetteloiden laajentamista.

Suunnittelu, joka kestää kosketuksen todelliseen toimistoverkkoon, on oletusta kapeampi: kolmirivinen selkeä päätöstaulukko, yksi pakotuskohta, jota ei voi ohittaa, ja kieltäytymistesti, joka todistaa jotakin. Oletuksen purkaminen tulee ensin, koska kaikki sen jälkeen riippuu siitä, että tiedetään mikä kerros esittää lähteen väärin.

Myytti: yhdistäminen ei ole reititystä

Tunneli muodostetaan, ja asiakasohjelma asentaa reitit joillekin etuliitteille. Se on kaikki, mitä yhdistäminen tekee. Kulkeeko asiaankuulumaton HTTPS-pyyntö tunnelin läpi ja miltä julkiselta osoitteelta se näyttää tulevan saapuessaan, ovat päätöksiä, jotka muut komponentit tekevät myöhemmin: reititystaulukko valitsee polun ja lähtöpiste valitsee lähteen.

Siksi toimisto ja keittiön pöytä erkanevat samalla kannettavalla, samalla selainprofiililla ja samalla kirjanmerkillä. Toimistossa pyyntö lähtee ylläpidetystä julkisesta osoitteesta, jonka sivuston ylläpitäjä on hyväksynyt. Kokonaisen tunnelin kautta se voi lähteä VPN-ulostulosta, joka on eri osoite ja kunnes joku lisää sen, hyväksymätön. Jaetun tunnelin kautta se ei ehkä koskaan tule tunneliin. Vain kaksi noista kolmesta polusta oli koskaan osa sivuston omistajan kanssa tehtyä sopimusta, ja kolmas ei ole vika, jota korjataan ylimääräisellä allow-rivillä.

Kolme pyyntötilaa, kaksi hyväksyttyä ulostuloa

Kirjoita matriisi muistiin ennen kuin kosket palomuuriin, koska taulukko on suunnittelu ja sääntö vain yksi sen toteutus. Alla olevat osoitteet ovat dokumentointialueita; korvaa ne omilla ylläpidetyillä arvoillasi ja pidä ne jossakin, missä sivuston omistaja voi auditoida ne.

Keskimmäinen rivi on paikka, jossa useimmat näistä suunnitelmista murtuvat. Ratkaisee osoite, jonka pakotuslaite näkee, ei yksityinen osoite, jonka kannettava pitää tunnelin sisällä, eikä sen LAN-osoite. Arvo kuten 10.8.0.6 ei merkitse julkiselle sivustolle mitään, eikä 192.168.1.44 myöskään. Tunneliosoite on tunnelin osoitteistuksen yksityiskohta, ei tunniste, jonka sivusto voi tarkistaa.

Jos VPN:si ei pysty tarjoamaan vakaata, dokumentoitua ulostuloa, matriisilla ei ole kelvollista keskiriviä eikä mikään määrä sallittujen luetteloita keksi sellaista. Rehelliset vaihtoehdot ovat silloin yksityinen sivusto, johon päästään selkeiden yksityisten reittien kautta, tai identiteettitietoinen käyttöyhdyskäytävä sovelluksen edessä. Molemmilla on erilainen sopimus kuin julkisella sallittujen luettelolla, ja molemmat on helpompi selittää tilintarkastajalle kuin luettelo, joka kasvoi kunnes se sattui toimimaan.

Lue lähdettä siellä, missä päätös tehdään

Aseta rajoitus laitteelle, joka päättää pyynnön, ja varmista, ettei mikään vaihtoehtoinen alkuperäpolku ohita sitä. Nginxin käyttöoikeusmoduuli arvioi allow- ja deny-direktiivit järjestyksessä, ensimmäinen osuma voittaa, ja ympäröivästä lohkosta perityt säännöt pätevät edelleen locationin sisällä. Kapea allow leveän allowin vieressä samassa paikassa tarkoittaa yleensä, että leveä päättää. Lue kyseisen locationin koko voimassa oleva kokoonpano ennen kuin muokkaat siitä yhtäkään riviä.

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

Kuormantasaajan tai käänteisen välityspalvelimen takana tuo sääntö näkee välityspalvelimen, ellet kerro sille muuta. Palauta kutsujan osoite vain tuetun luotetun välityspalvelimen mekanismin kautta, selkeällä välityspalvelinosoitteiden luettelolla. Hyväksyttyä osoitetta väittävä pyyntöotsake ei ole todiste siitä, että kutsuja omistaa sen, ja julkisessa kuuntelijassa validoimaton välitetty otsake tekee sallittujen luettelosta koristeen.

Tarkista sitten toinen osoiteperhe. Vain IPv4:n kattava sääntöjoukko on puutteellinen päätös isäntänimelle, joka vastaa myös AAAA:han, ja toimivalla IPv6:lla varustettu asiakas saavuttaa saman sovelluksen polkua, jota et koskaan tarkistanut.

Jaettu tunneli: pyyntö, joka ei koskaan tule sisään

Jaettu tunneli kuljettaa vain luettelossaan olevat etuliitteet. Toimiston sisäiset aliverkot kuuluvat yleensä siihen luetteloon; julkinen verkkosivusto ei. Selain ratkaisee nimen, vertaa valittua osoitetta reititystaulukkoon ja löytää silti paikallisen oletusyhdyskäytävän eteensä.

Niinpä pyyntö saapuu käyttäjän kotiyhteydestä, hylätään, ja raportti kertoo VPN:n olevan rikki, kun tunneli tekee täsmälleen sen, mihin se määritettiin. Kaksi korjausta on laillista: reititä tuo kohde tunnelin kautta ja anna hyväksytyn ulostulon kantaa se, tai hyväksy, että sivusto saavutetaan suoraan, ja anna etäkäyttäjille toinen hyväksytty polku, kuten käyttöyhdyskäytävä. Sivuston julkisen sallittujen luettelon laajentaminen, kunnes kotiosoite sattumalta sisältyy, ei ole kumpikaan niistä, ja se poistaa rajan, joka suunnittelun oli määrä pakottaa. Kaksi ensimmäistä pitävät matriisin rehellisenä; kolmas poistaa siitä hiljaa rivin.

Todista kieltäytyminen ja sitten palautuminen

Testaa pyynnöllä, joka harjoittaa todellista päätöstä, asiakkaalta, joka seisoo taulukon jokaisella rivillä. Saavutettavuustarkistus jotakin asiaankuulumatonta osoitteen näyttävää sivua vastaan ei todista mitään, koska tuo kohde voi seurata eri reittiä kuin sovellus.

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

Vertaa rajan käyttöoikeustietuetta siihen, mitä taulukko ennusti. Laske sitten tunneli alas ja tee uusi pyyntö, joka pitäisi hylätä; jo ladattu sivu tai jo avattu yhteys ei testaa yhtään mitään. Jos kieltäytymistä ei ilmesty, pakotuskohta ei ole siellä, missä luulet sen olevan.

Pidä sovelluksen todennus verkkohyväksynnän jälkeen, koska toimiston ulostulo ja VPN-ulostulo edustavat kumpikin monia ihmisiä eikä kumpikaan tunnista yksilöä. Ohje käyttäjille pysyy lyhyenä: nosta hyväksytty tunneli ja yritä uudelleen. Juuri se pitää yhden URL:n kätevänä, kun lähdesääntö pysyy päätöksenä eikä arvauksena.