Egyetlen URL az irodához és a VPN-hez? Miért bukik meg az engedélyezési lista mítosza

Csatlakoztassa az alagutat, nyissa meg ugyanazt a könyvjelzőt, és az engedélyezett oldal pontosan úgy válaszol, ahogy az irodából tette. Ez az a feltevés, amelyen a legtöbb távoli hozzáférési terv csendben nyugszik, és csak addig áll, amíg három különálló dolog egyszerre igaz marad. Egyik sem a VPN-kliens funkciója, és egyetlen DNS-rekord sem tud egyiket sem nyújtani. Amikor a könyvjelző otthon meghiúsul, a böngésző egyetlen általános hibát ad, akár hiányzó útvonal, akár nem jóváhagyott kilépési cím, akár olyan proxy az ok, amely lecserélte a jelentett forrást. Ezt a hármat egyetlen problémaként kezelni az az út, amelyen egy kis házirend-javítás az engedélyezési listák bővítésének egy hetévé válik.

Az a kialakítás, amely túlél egy valódi irodai hálózattal való találkozást, szűkebb a feltevésnél: egy kifejezett, háromsoros döntési táblázat, egy kikerülhetetlen érvényesítési pont és egy tagadási teszt, amely bizonyít valamit. A feltevés lebontása jön előbb, mert minden utána attól függ, hogy tudjuk, melyik réteg mutatja be hibásan a forrást.

A mítosz: a csatlakozás nem útválasztás

Létrejön egy alagút, és a kliens útvonalakat telepít bizonyos előtagok halmazához. Ennyi az egész, amit a csatlakozás tesz. Hogy egy független HTTPS-kérés átmegy-e az alagúton, és melyik nyilvános címről látszik érkezni, amikor megérkezik, azok olyan döntések, amelyeket később más komponensek hoznak: az útválasztási táblázat választja az útvonalat, és a kilépés választja a forrást.

Ezért tér el az iroda és a konyhaasztal ugyanazzal a laptoppal, ugyanazzal a böngészőprofillal és ugyanazzal a könyvjelzővel. Az irodában a kérés egy karbantartott nyilvános címen keresztül lép ki, amelyhez az oldal üzemeltetője hozzájárult. Teljes alagúton keresztül a VPN-kimeneten léphet ki, amely más cím, és amíg valaki hozzá nem adja, nem jóváhagyott. Osztott alagúton keresztül lehet, hogy egyáltalán nem lép be az alagútba. Csak két ilyen útvonal volt valaha része az oldal tulajdonosával kötött megállapodásnak, a harmadik pedig nem olyan hiba, amelyet egy extra allow sorral kell foltozni.

Három kérésállapot, két jóváhagyott kilépés

Írja le a mátrixot, mielőtt tűzfalhoz nyúl, mert a táblázat a kialakítás, és a szabály csak annak egyetlen megvalósítása. Az alábbi címek dokumentációs tartományok; cserélje ki őket saját karbantartott értékeire, és tartsa olyan helyen, ahol az oldal tulajdonosa ellenőrizheti őket.

A középső sor az, ahol ezeknek a terveknek a többsége eltörik. Az számít, amit az érvényesítő eszköz lát, nem a laptop privát címe az alagúton belül, és nem annak LAN-címe. Egy olyan érték, mint a 10.8.0.6, semmit sem jelent egy nyilvános oldalnak, és a 192.168.1.44 sem. Az alagút címe az alagút címzésének részlete, nem olyan tanúsítvány, amelyet az oldal ellenőrizhet.

Ha a VPN-je nem tud stabil, dokumentált kimenetet biztosítani, a mátrixnak nincs érvényes középső sora, és semmilyen mennyiségű engedélyezési lista nem talál ki egyet. Az őszinte lehetőségek ekkor egy kifejezett privát útvonalakon elérhető privát oldal, vagy egy identitástudatos hozzáférési átjáró az alkalmazás előtt. Mindkettőnek más a szerződése, mint egy nyilvános engedélyezési listának, és mindkettőt könnyebb elmagyarázni egy ellenőrnek, mint egy listát, amely addig nőtt, amíg véletlenül működni nem kezdett.

Ott olvassa a forrást, ahol a döntés születik

Tegye a korlátozást arra az eszközre, amely a kérést lezárja, és erősítse meg, hogy egyetlen alternatív eredeti útvonal sem kerüli meg. A Nginx hozzáférési modul sorrendben értékeli az allow és deny utasításokat, az első egyezés nyer, és a körülvevő blokkból örökölt szabályok a location belsejében is érvényesek maradnak. Egy szűk allow egy széles allow mellett ugyanazon a helyen általában azt jelenti, hogy a széles dönt. Olvassa el a location teljes hatályos konfigurációját, mielőtt annak akár egyetlen sorát szerkeszti.

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

Terheléselosztó vagy fordított proxy mögött az a szabály a proxyt látja, hacsak nem mond mást neki. Csak a támogatott megbízható proxy mechanizmuson keresztül állítsa vissza a hívó címét, kifejezett proxycímlistával. Egy jóváhagyott címet állító kérésfejléc nem bizonyítja, hogy a hívó birtokolja, és egy nyilvános figyelőn az érvényesítetlen továbbított fejléc díszletté teszi az engedélyezési listát.

Utána ellenőrizze a másik címcsaládot. A csak IPv4-et lefedő szabálykészlet hiányos döntés egy olyan hosztnévhez, amely AAAA-n is válaszol, és egy működő IPv6-tal rendelkező kliens ugyanazt az alkalmazást olyan útvonalon éri el, amelyet soha nem vizsgált meg.

Osztott alagút: a kérés, amely soha nem lép be

Az osztott alagút csak a listáján szereplő előtagokat szállítja. Az irodai belső alhálózatok általában felkerülnek erre a listára; egy nyilvános weboldal nem. A böngésző feloldja a nevet, összeveti a választott címet az útválasztási táblázattal, és mégis megtalálja maga előtt a helyi alapértelmezett átjárót.

Így a kérés a felhasználó otthoni kapcsolatáról érkezik, elutasításra kerül, és a jelentés azt mondja, hogy a VPN elromlott, miközben az alagút pontosan azt teszi, amire beállították. Két javítás jogszerű: irányítsa azt a célt az alagúton keresztül, és hagyja, hogy a jóváhagyott kimenet vigye, vagy fogadja el, hogy az oldal közvetlenül elérhető, és adjon a távoli felhasználóknak egy másik jóváhagyott útvonalat, például a hozzáférési átjárót. Az oldal nyilvános engedélyezési listáját addig bővíteni, amíg véletlenül bele nem kerül egy otthoni cím, egyik sem, és eltávolítja azt a határt, amelyet a kialakításnak érvényesítenie kellett. Az első kettő őszintén tartja a mátrixot; a harmadik csendben töröl belőle egy sort.

Bizonyítsa a tagadást, majd a helyreállást

Teszteljen olyan kéréssel, amely a valódi döntést gyakorolja, a táblázat minden során álló kliensről. Egy kapcsolódási ellenőrzés valamilyen független, címet mutató oldal felé semmit sem bizonyít, mert az a cél az alkalmazástól eltérő útvonalat követhet.

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

Hasonlítsa össze a határ hozzáférési rekordját azzal, amit a táblázat előre jelzett. Utána engedje le az alagutat, és tegyen egy új kérést, amelyet el kellene utasítani; egy már betöltött oldal vagy egy már nyitott kapcsolat semmit sem tesztel. Ha nem jelenik meg tagadás, az érvényesítési pont nem ott van, ahol gondolja.

Tartsa meg az alkalmazás hitelesítését a hálózati beengedés után, mert az irodai kilépés és a VPN-kimenet egyaránt sok embert képvisel, és egyik sem azonosít egyént. Az utasítás a felhasználóknak rövid marad: hozza fel a jóváhagyott alagutat, majd próbálja újra. Ez tartja kényelmessé az egyetlen URL-t, miközben a forrásszabály döntés marad, nem találgatás.