Jedna URL pro kancelář i VPN? Proč mýtus o seznamu povolených selhává

Připojte tunel, otevřete stejnou záložku a autorizovaný web odpovídá přesně jako z kanceláře. To je předpoklad, na kterém většina plánů vzdáleného přístupu tiše stojí, a platí jen tehdy, dokud tři oddělené věci zůstávají současně pravdivé. Ani jedna z nich není funkcí VPN klienta a žádný DNS záznam nemůže poskytnout kteroukoli z nich. Když záložka doma selže, prohlížeč vám dá jednu obecnou chybu, ať už je příčinou chybějící trasa, neschválená výstupní adresa nebo proxy, která nahradila zdroj, o kterém informuje. Považovat ty tři za jediný problém je způsob, jak se malá oprava politiky promění v týden rozšiřování seznamů povolených.

Návrh, který přežije střet s reálnou kancelářskou sítí, je užší než předpoklad: výslovná rozhodovací tabulka o třech řádcích, jeden vynucovací bod, který nelze obejít, a test odmítnutí, který něco dokazuje. Rozebrání předpokladu přichází první, protože vše po něm závisí na tom, vědět, která vrstva zkresluje zdroj.

Mýtus: připojení není směrování

Tunel se naváže a klient nainstaluje trasy pro nějakou množinu prefixů. To je vše, co připojení dělá. Zda nesouvisející požadavek HTTPS projde tunelem a ze které veřejné adresy to vypadá, že přichází, když dorazí, jsou rozhodnutí, která později činí jiné komponenty: směrovací tabulka volí cestu a výstup volí zdroj.

Proto se kancelář a kuchyňský stůl rozcházejí se stejným notebookem, stejným profilem prohlížeče a stejnou záložkou. V kanceláři požadavek vychází přes udržovanou veřejnou adresu, se kterou provozovatel webu souhlasil. Plným tunelem může vyjít přes výstup VPN, což je jiná adresa a dokud ji někdo nepřidá, neschválená. Rozděleným tunelem nemusí do tunelu vůbec vstoupit. Jen dvě z těchto tří cest byly kdy součástí dohody s vlastníkem webu a třetí není vada, kterou je třeba zalepit dalším řádkem allow.

Tři stavy požadavku, dva schválené výstupy

Zapište matici, než se dotknete firewallu, protože tabulka je návrh a pravidlo je jen jedna jeho implementace. Adresy níže jsou dokumentační rozsahy; nahraďte je svými udržovanými hodnotami a uložte je tam, kde je vlastník webu může auditovat.

Prostřední řádek je místo, kde se většina těchto plánů láme. Rozhoduje adresa, kterou vidí vynucovací zařízení, ne privátní adresa, kterou notebook drží uvnitř tunelu, ani jeho adresa v LAN. Hodnota jako 10.8.0.6 pro veřejný web nic neznamená, stejně jako 192.168.1.44. Adresa tunelu je detail adresování tunelu, ne pověření, které web může ověřit.

Pokud vaše VPN nemůže poskytnout stabilní, dokumentovaný výstup, matice nemá platný prostřední řádek a žádné množství seznamů povolených ho nevymyslí. Poctivé možnosti jsou v tu chvíli privátní web dostupný přes výslovné privátní trasy, nebo přístupová brána s ohledem na identitu před aplikací. Obě mají jinou smlouvu než veřejný seznam povolených a obě se auditují snáze než seznam, který rostl, dokud náhodou nefungoval.

Čtěte zdroj tam, kde se rozhoduje

Umístěte omezení na zařízení, které požadavek ukončuje, a potvrďte, že ho žádná alternativní cesta původu neobchází. Přístupový modul Nginx vyhodnocuje direktivy allow a deny v pořadí, vyhrává první shoda a pravidla zděděná z obklopujícího bloku stále platí uvnitř location. Úzké allow vedle širokého allow na stejném místě obvykle znamená, že rozhoduje široké. Přečtěte celou účinnou konfiguraci pro daný location, než v ní upravíte jediný řádek.

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 vyvažovačem zátěže nebo reverzní proxy to pravidlo vidí proxy, pokud mu neřeknete jinak. Obnovujte adresu volajícího jen podporovaným mechanismem důvěryhodné proxy, s výslovným seznamem adres proxy. Hlavička požadavku tvrdící schválenou adresu není důkazem, že ji volající vlastní, a na veřejném posluchači nevalidovaná předávaná hlavička promění seznam povolených v dekoraci.

Pak zkontrolujte druhou rodinu adres. Sada pravidel pokrývající jen IPv4 je neúplné rozhodnutí pro název hostitele, který odpovídá i na AAAA, a klient s funkčním IPv6 dosáhne stejné aplikace cestou, kterou jste nikdy neprověřili.

Rozdělený tunel: požadavek, který nikdy nevstoupí

Rozdělený tunel nese jen prefixy ze svého seznamu. Interní kancelářské podsítě se na tento seznam obvykle dostanou; veřejný web ne. Prohlížeč přeloží název, porovná zvolenou adresu se směrovací tabulkou a přesto najde před sebou místní výchozí bránu.

Požadavek tedy dorazí z domácího připojení uživatele, je odmítnut a zpráva říká, že VPN je rozbitá, zatímco tunel dělá přesně to, k čemu byl nakonfigurován. Dvě opravy jsou legitimní: nasměrujte ten cíl tunelem a nechte schválený výstup, ať ho nese, nebo přijměte, že web je dostupný přímo, a dejte vzdáleným uživatelům jinou schválenou cestu, například přístupovou bránu. Rozšiřování veřejného seznamu povolených webu, dokud do něj náhodou nepadne domácí adresa, není ani jedno z toho a odstraňuje hranici, kterou měl návrh vynucovat. První dvě drží matici poctivou; třetí z ní tiše maže řádek.

Dokažte odmítnutí, pak obnovení

Testujte požadavkem, který procvičí skutečné rozhodnutí, z klienta stojícího na každém řádku tabulky. Kontrola dostupnosti vůči nějaké nesouvisející stránce zobrazující adresu nic nedokazuje, protože ten cíl může sledovat jinou trasu než aplikace.

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

Porovnejte záznam přístupu na hranici s tím, co tabulka předpověděla. Pak sundejte tunel a pošlete nový požadavek, který by měl být odmítnut; již načtená stránka nebo již otevřené spojení netestuje vůbec nic. Pokud se odmítnutí neobjeví, vynucovací bod není tam, kde si myslíte.

Zachovejte autentizaci aplikace po síťovém přijetí, protože kancelářský výstup a výstup VPN každý zastupuje mnoho lidí a ani jeden neidentifikuje jednotlivce. Pokyn pro uživatele zůstává krátký: zapněte schválený tunel a zkuste to znovu. To je to, co drží jednu URL pohodlnou, zatímco pravidlo o zdroji zůstává rozhodnutím, ne hádáním.