Jedna URL pre kanceláriu aj VPN? Prečo mýtus o zozname povolených zlyháva
Pripojenie VPN nemení adresu, ktorú povolená lokalita vidí. Overte skutočný výstup, skok dôveryhodného proxy a cestu IPv6, kým pridáte URL.
Pripojte tunel, otvorte tú istú záložku a povolená lokalita odpovedá presne tak, ako odpovedala z kancelárie. To je predpoklad, na ktorom väčšina plánov vzdialeného prístupu potichu stojí, a platí len dovtedy, kým tri oddelené veci zostávajú súčasne pravdivé. Ani jedna z nich nie je funkciou klienta VPN a žiadny DNS záznam nemôže poskytnúť ani jednu z nich. Keď záložka doma zlyhá, prehliadač vám dá jednu všeobecnú chybu, nech je príčinou chýbajúca trasa, neschválená výstupná adresa alebo proxy, ktorá nahradila zdroj, o ktorom informuje. Správa sa k tým trom ako k jedinému problému je cesta, ktorou sa malá oprava politiky zmení na týždeň rozširovania zoznamov povolených.
Dizajn, ktorý prežije stretnutie s reálnou kancelárskou sieťou, je užší než predpoklad: výslovná rozhodovacia tabuľka s tromi riadkami, jeden bod presadenia, ktorý sa nedá obísť, a test odmietnutia, ktorý niečo dokazuje. Demontáž predpokladu prichádza prvá, pretože všetko po nej závisí od toho vedieť, ktorá vrstva nesprávne zobrazuje zdroj.
Mýtus: pripojenie nie je smerovanie
Vytvorí sa tunel a klient nainštaluje trasy pre určitú množinu prefixov. To je všetko, čo pripojenie robí. Či nesúvisiaca požiadavka HTTPS pôjde tunelom a z ktorej verejnej adresy to vyzerá, že prichádza, keď dorazí, sú rozhodnutia, ktoré neskôr prijímajú iné komponenty: smerovacia tabuľka vyberá cestu a výstup vyberá zdroj.
Preto sa kancelária a kuchynský stôl rozchádzajú s tým istým notebookom, tým istým profilom prehliadača a tou istou záložkou. V kancelárii požiadavka vychádza cez udržiavanú verejnú adresu, s ktorou prevádzkovateľ lokality súhlasil. Cez plný tunel môže vyjsť cez výstup VPN, čo je iná adresa a kým ju niekto nepridá, neschválená. Cez rozdelený tunel nemusí do tunela vôbec vstúpiť. Len dve z týchto troch ciest boli niekedy súčasťou dohody s vlastníkom lokality a tretia nie je chyba, ktorú treba zaplátať ďalším riadkom allow.
Tri stavy požiadavky, dva schválené výstupy
Zapíšte maticu skôr, než sa dotknete firewallu, pretože tabuľka je dizajn a pravidlo iba jedno jeho vykonanie. Adresy nižšie sú dokumentačné rozsahy; nahraďte ich svojimi udržiavanými hodnotami a uložte ich tam, kde ich vlastník lokality môže auditovať.
| Request path | Source the site sees | Intended decision |
|---|---|---|
| Office, no tunnel | Office public exit | Admit to the application login |
| Remote, approved full tunnel | Approved VPN egress | Admit to the same login |
| Remote, ordinary connection | Neither approved address | Deny at the network boundary |
Práve v strednom riadku sa väčšina týchto plánov láme. Dôležitá je adresa, ktorú vidí zariadenie presadenia, nie súkromná adresa, ktorú notebook drží vnútri tunela, ani jeho adresa v LAN. Hodnota ako 10.8.0.6 nič neznamená pre verejnú lokalitu, a 192.168.1.44 tiež nie. Adresa tunela je detail adresovania tunela, nie poverenie, ktoré lokalita môže overiť.
Ak vaša VPN nedokáže poskytnúť stabilný, zdokumentovaný výstup, matica nemá platný stredný riadok a žiadne množstvo zoznamov povolených ho nevymyslí. Čestné možnosti sú vtedy súkromná lokalita dostupná cez výslovné súkromné trasy alebo prístupová brána s ohľadom na identitu pred aplikáciou. Obe majú inú zmluvu než verejný zoznam povolených a obe sa audítorovi vysvetľujú ľahšie než zoznam, ktorý rástol, kým náhodou nezačal fungovať.
Čítajte zdroj tam, kde sa rozhoduje
Umiestnite obmedzenie na zariadenie, ktoré požiadavku ukončuje, a potvrďte, že ho neobchádza žiadna alternatívna cesta pôvodu. Prístupový modul Nginx vyhodnocuje direktívy allow a deny v poradí, vyhráva prvý zhoda, a pravidlá zdedené z obklopujúceho bloku stále platia vnútri location. Úzke allow vedľa širokého allow na tom istom mieste zvyčajne znamená, že rozhoduje to široké. Prečítajte celú účinnú konfiguráciu pre daný location, kým v nej upravíte čo i len jeden riadok.
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čom záťaže alebo reverzným proxy to pravidlo vidí proxy, ak mu nepoviete inak. Obnovte adresu volajúceho iba podporovaným mechanizmom dôveryhodného proxy, s výslovným zoznamom adries proxy. Hlavička požiadavky tvrdiaca schválenú adresu nie je dôkazom, že ju volajúci vlastní, a na verejnom poslucháčovi nevalidovaná preposlaná hlavička premení zoznam povolených na dekoráciu.
Potom skontrolujte druhú rodinu adries. Sada pravidiel pokrývajúca iba IPv4 je neúplné rozhodnutie pre názov hostiteľa, ktorý odpovedá aj na AAAA, a klient s funkčným IPv6 dosiahne tú istú aplikáciu cestou, ktorú ste nikdy nepreskúmali.
Rozdelený tunel: požiadavka, ktorá nikdy nevstúpi
Rozdelený tunel nesie iba prefixy zo svojho zoznamu. Interné kancelárske podsiete sa na tento zoznam zvyčajne dostanú; verejná webová lokalita nie. Prehliadač preloží názov, porovná zvolenú adresu so smerovacou tabuľkou a napriek tomu nájde pred sebou miestnu predvolenú bránu.
Požiadavka teda prichádza z domáceho pripojenia používateľa, je odmietnutá a správa hovorí, že VPN je pokazená, kým tunel robí presne to, na čo bol nakonfigurovaný. Dve opravy sú legitímne: nasmerujte ten cieľ tunelom a nechajte schválený výstup, aby ho niesol, alebo prijmite, že lokalita je dostupná priamo, a dajte vzdialeným používateľom inú schválenú cestu, napríklad prístupovú bránu. Rozširovanie verejného zoznamu povolených lokality, kým doň náhodou nepadne domáca adresa, nie je ani jedno z toho, a odstraňuje hranicu, ktorú mal dizajn presadiť. Prvé dve držia maticu čestnou; tretia z nej potichu vymaže riadok.
Dokážte odmietnutie, potom obnovenie
Testujte požiadavkou, ktorá precvičí skutočné rozhodnutie, z klienta stojaceho na každom riadku tabuľky. Kontrola dostupnosti voči nejakej nesúvisiacej stránke zobrazujúcej adresu nič nedokazuje, pretože ten cieľ môže sledovať inú cestu než aplikácia.
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/'
Porovnajte záznam prístupu na hranici s tým, čo tabuľka predpovedala. Potom spustite tunel a pošlite novú požiadavku, ktorá by mala byť odmietnutá; už načítaná stránka alebo už otvorené spojenie netestuje vôbec nič. Ak sa odmietnutie neobjaví, bod presadenia nie je tam, kde si myslíte.
Zachovajte autentifikáciu aplikácie po prijatí do siete, pretože kancelársky výstup a výstup VPN každý zastupuje mnoho ľudí a ani jeden neidentifikuje jednotlivca. Pokyn pre používateľov zostáva krátky: zdvihnite schválený tunel a skúste to znova. To je to, čo drží jednu URL pohodlnou, kým pravidlo o zdroji zostáva rozhodnutím, nie hádaním.