En sam URL za pisarno in VPN? Zakaj mit o seznamu dovoljenih odpove

Povežite tunel, odprite isti zaznamek in dovoljeno spletišče odgovori natanko tako, kot je odgovarjalo iz pisarne. To je predpostavka, na kateri tiho sloni večina načrtov oddaljenega dostopa, in velja le, dokler tri ločene stvari ostajajo hkrati resnične. Nobena od njih ni funkcija odjemalca VPN in noben zapis DNS ne more zagotoviti nobene. Ko zaznamek doma odpove, vam brskalnik pokaže eno splošno napako, ne glede na to, ali je vzrok manjkajoča pot, neodobren izhodni naslov ali posrednik, ki je zamenjal vir, o katerem poroča. Obravnavanje teh treh kot ene same težave je pot, po kateri se majhen popravek politike spremeni v teden širjenja seznamov dovoljenih.

Zasnova, ki preživi stik z resničnim pisarniškim omrežjem, je ožja od predpostavke: izrecna odločitvena tabela s tremi vrsticami, ena točka uveljavljanja, ki se ji ni mogoče izogniti, in preizkus zavrnitve, ki nekaj dokaže. Razstavljanje predpostavke pride prvo, ker je vse za njim odvisno od vedenja, kateri sloj vir predstavlja napačno.

Mit: povezovanje ni usmerjanje

Vzpostavi se tunel in odjemalec namesti poti za neko množico predpon. To je vse, kar povezovanje naredi. Ali bo nepovezana zahteva HTTPS potovala skozi tunel in s katerega javnega naslova se zdi, da prihaja, ko prispe, so odločitve, ki jih pozneje sprejmejo druge komponente: usmerjevalna tabela izbere pot, izhod pa izbere vir.

Zato se pisarna in kuhinjska miza razhajata z istim prenosnikom, istim profilom brskalnika in istim zaznamkom. V pisarni zahteva odide skozi vzdrževani javni naslov, s katerim se je upravljavec spletišča strinjal. Skozi polni tunel lahko odide skozi izhod VPN, ki je drug naslov in dokler ga nekdo ne doda, neodobren. Skozi razdeljeni tunel morda sploh ne vstopi v tunel. Le dve od teh treh poti sta bili kdaj del dogovora z lastnikom spletišča, tretja pa ni napaka, ki bi jo bilo treba zakrpati z dodatno vrstico allow.

Tri stanja zahteve, dva odobrena izhoda

Zapišite matriko, preden se dotaknete požarnega zidu, ker je tabela zasnova in pravilo le ena njena izvedba. Naslovi spodaj so dokumentacijska območja; zamenjajte jih s svojimi vzdrževanimi vrednostmi in jih hranite tam, kjer jih lastnik spletišča lahko pregleda.

Prav v srednji vrstici se večina teh načrtov zlomi. Pomemben je naslov, ki ga vidi naprava za uveljavljanje, ne zasebni naslov, ki ga prenosnik hrani v tunelu, in ne njegov naslov LAN. Vrednost, kot je 10.8.0.6, za javno spletišče ne pomeni nič, tudi 192.168.1.44 ne. Naslov tunela je podrobnost naslavljanja tunela, ne poverilnica, ki jo spletišče lahko preveri.

Če vaš VPN ne more zagotoviti stabilnega, dokumentiranega izhoda, matrika nima veljavne srednje vrstice in nobena količina seznamov dovoljenih je ne izmisli. Poštene možnosti so takrat zasebno spletišče, dosegljivo po izrecnih zasebnih poteh, ali dostopni prehod, ki se zaveda identitete, pred aplikacijo. Oba imata drugačno pogodbo od javnega seznama dovoljenih in oba je revizorju lažje razložiti kot seznam, ki je rasel, dokler ni po naključju začel delovati.

Preberite vir tam, kjer se odločitev sprejme

Omejitev postavite na napravo, ki zahtevo zaključi, in potrdite, da je nobena druga pot izvora ne obide. Dostopni modul Nginx ovrednoti direktivi allow in deny po vrsti, zmaga prvo ujemanje, pravila, podedovana iz obdajajočega bloka, pa še vedno veljajo znotraj location. Ozek allow ob širokem allow na istem mestu običajno pomeni, da odloča široki. Preberite celotno veljavno konfiguracijo za ta location, preden spremenite eno samo njeno vrstico.

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

Za uravnavalnikom obremenitve ali obratnim posrednikom to pravilo vidi posrednika, razen če mu poveste drugače. Naslov klicatelja obnovite samo prek podprtega mehanizma zaupanja vrednega posrednika, z izrecnim seznamom naslovov posrednikov. Glava zahteve, ki trdi, da je naslov odobren, ni dokaz, da ga klicatelj ima, in na javnem poslušalcu nepreverjena posredovana glava spremeni seznam dovoljenih v okras.

Nato preverite drugo družino naslovov. Nabor pravil, ki pokriva samo IPv4, je nepopolna odločitev za ime gostitelja, ki odgovarja tudi na AAAA, in odjemalec z delujočim IPv6 bo dosegel isto aplikacijo po poti, ki je nikoli niste pregledali.

Razdeljeni tunel: zahteva, ki nikoli ne vstopi

Razdeljeni tunel prenaša samo predpone s svojega seznama. Notranja pisarniška podomrežja običajno pridejo na ta seznam; javno spletišče ne. Brskalnik razreši ime, primerja izbrani naslov z usmerjevalno tabelo in kljub temu pred seboj najde krajevna privzeta prehodna vrata.

Tako zahteva prispe iz uporabnikove domače povezave, je zavrnjena, poročilo pa pravi, da je VPN pokvarjen, medtem ko tunel dela natanko to, za kar je bil nastavljen. Dva popravka sta zakonita: usmerite to ciljno mesto skozi tunel in pustite odobrenemu izhodu, da ga nosi, ali priznajte, da je spletišče dosegljivo neposredno, in oddaljenim uporabnikom dajte drugo odobreno pot, na primer dostopni prehod. Širjenje javnega seznama dovoljenih spletišča, dokler vanj po naključju ne pade domači naslov, ni ne eno ne drugo in odvzame mejo, ki naj bi jo zasnova uveljavljala. Prva dva ohranjata matriko pošteno; tretji tiho izbriše vrstico iz nje.

Dokažite zavrnitev, nato obnovitev

Preizkusite z zahtevo, ki izvaja resnično odločitev, z odjemalca, ki stoji v vsaki vrstici tabele. Preverjanje dosegljivosti do neke nepovezane strani, ki prikazuje naslov, ne dokaže ničesar, ker lahko to ciljno mesto sledi drugačni poti kot aplikacija.

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

Primerjajte zapis dostopa na meji s tem, kar je tabela predvidela. Nato spustite tunel in naredite novo zahtevo, ki bi morala biti zavrnjena; že naložena stran ali že odprta povezava ne preizkusi prav ničesar. Če se zavrnitev ne pojavi, točka uveljavljanja ni tam, kjer mislite.

Ohranite preverjanje pristnosti aplikacije po sprejemu v omrežje, ker pisarniški izhod in izhod VPN vsak zastopa veliko ljudi in nobeden ne identificira posameznika. Navodilo za uporabnike ostaja kratko: dvignite odobreni tunel in poskusite znova. To je tisto, kar ohranja en sam URL priročen, medtem ko pravilo o viru ostaja odločitev in ne ugibanje.