Jedan URL za ured i VPN? Zašto mit o listi dopuštenih propada

Povežite tunel, otvorite istu oznaku i sajt sa liste dopuštenih odgovara tačno kao iz ureda. To je pretpostavka na kojoj većina planova daljinskog pristupa tiho počiva, a vrijedi samo dok tri odvojene stvari istovremeno ostaju istinite. Nijedna od njih nije funkcija VPN klijenta i nijedan DNS zapis ne može osigurati bilo koju od njih. Kada oznaka ne uspije kod kuće, preglednik vam daje jednu generičku grešku, bilo da je uzrok nedostajuća ruta, neodobrena izlazna adresa ili proksi koji je zamijenio izvor koji prijavljuje. Tretiranje te tri kao jednog problema jeste način na koji mala popravka politike postaje sedmica širenja lista dopuštenih.

Dizajn koji preživi susret sa stvarnom uredskom mrežom uži je od pretpostavke: eksplicitna tablica odluka od tri reda, jedna tačka provođenja koja se ne može zaobići i test odbijanja koji nešto dokazuje. Razgradnja pretpostavke dolazi prva, jer sve poslije nje zavisi od toga da se zna koji sloj pogrešno predstavlja izvor.

Mit: povezivanje nije rutiranje

Tunel se uspostavlja i klijent instalira rute za neki skup prefiksa. To je sve što povezivanje čini. Da li će nepovezan HTTPS zahtjev proći kroz tunel i s koje javne adrese izgleda da dolazi kada stigne, odluke su koje kasnije donose druge komponente: tablica rutiranja bira put, a izlaz bira izvor.

Zato se ured i kuhinjski sto razilaze s istim laptopom, istim profilom preglednika i istom oznakom. U uredu zahtjev izlazi kroz održavanu javnu adresu s kojom se operater sajta saglasio. Kroz puni tunel može izaći kroz VPN izlaz, koji je druga adresa i, dok ga neko ne doda, neodobrena. Kroz podijeljeni tunel možda uopće ne uđe u tunel. Samo su dvije od te tri putanje ikada bile dio dogovora s vlasnikom sajta, a treća nije kvar koji treba zakrpati dodatnim allow unosom.

Tri stanja zahtjeva, dva odobrena izlaza

Zapišite matricu prije nego dotaknete firewall, jer tablica je dizajn, a pravilo je samo jedna njegova implementacija. Adrese ispod su dokumentacijski rasponi; zamijenite ih svojim održavanim vrijednostima i čuvajte ih negdje gdje ih vlasnik sajta može provjeriti.

Srednji red je mjesto gdje se većina ovih planova lomi. Važna je adresa koju vidi uređaj za provođenje, ne privatna adresa koju laptop drži unutar tunela i ne njegova LAN adresa. Vrijednost poput 10.8.0.6 ne znači ništa javnom sajtu, kao ni 192.168.1.44. Adresa tunela je detalj adresiranja tunela, a ne akreditiv koji sajt može provjeriti.

Ako vaš VPN ne može osigurati stabilan, dokumentovan izlaz, matrica nema valjan srednji red i nikakva količina lista dopuštenih ga neće izmisliti. Iskrene opcije u tom trenutku su privatni sajt dostupan preko eksplicitnih privatnih ruta ili pristupni gateway svjestan identiteta ispred aplikacije. Oba imaju drugačiji ugovor od javne liste dopuštenih i oba je lakše objasniti revizoru nego listu koja je rasla dok slučajno nije proradila.

Čitajte izvor tamo gdje se odluka donosi

Stavite ograničenje na uređaj koji završava zahtjev i potvrdite da ga nijedna alternativna putanja porijekla ne zaobilazi. Nginx modul za pristup ocjenjuje allow i deny direktive redom, prvo podudaranje pobjeđuje, a pravila naslijeđena iz obuhvatajućeg bloka i dalje važe unutar location. Usko allow pored širokog allow na istom mjestu obično znači da odlučuje široko. Pročitajte cijelu efektivnu konfiguraciju za taj location prije nego uredite i jedan njen red.

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

Iza balansera opterećenja ili obrnutog proksija to pravilo vidi proksi, osim ako mu ne kažete drugačije. Vratite adresu pozivaoca samo kroz podržani mehanizam pouzdanog proksija, s eksplicitnom listom adresa proksija. Zaglavlje zahtjeva koje tvrdi odobrenu adresu nije dokaz da je pozivalac posjeduje, a na javnom slušaocu nevalidirano proslijeđeno zaglavlje pretvara listu dopuštenih u ukras.

Zatim provjerite drugu familiju adresa. Skup pravila koji pokriva samo IPv4 je nepotpuna odluka za ime hosta koje odgovara i na AAAA, a klijent s ispravnim IPv6 doći će do iste aplikacije putem koju nikada niste pregledali.

Podijeljeni tunel: zahtjev koji nikada ne ulazi

Podijeljeni tunel nosi samo prefikse sa svoje liste. Interne uredske podmreže obično ulaze na tu listu; javni veb sajt ne. Preglednik razrješava ime, upoređuje odabranu adresu s tablicom rutiranja i ipak pronalazi lokalni podrazumijevani gateway ispred sebe.

Tako zahtjev dolazi s korisnikove kućne veze, biva odbijen, a izvještaj kaže da je VPN pokvaren dok tunel radi upravo ono za što je konfigurisan. Dvije popravke su legitimne: usmjerite tu destinaciju kroz tunel i pustite odobreni izlaz da je nosi, ili prihvatite da se sajtu pristupa direktno i dajte daljinskim korisnicima drugu odobrenu putanju poput pristupnog gatewaya. Širenje javne liste dopuštenih sajta dok se slučajno ne uključi kućna adresa nije nijedno od toga i uklanja granicu koju je dizajn trebao provoditi. Prve dvije drže matricu iskrenom; treća tiho briše red iz nje.

Dokažite odbijanje, zatim oporavak

Testirajte zahtjevom koji pokreće stvarnu odluku, s klijenta koji stoji na svakom redu tablice. Provjera dostupnosti prema nekoj nepovezanoj stranici koja prikazuje adresu ne dokazuje ništa, jer ta destinacija može slijediti drugačiju rutu od aplikacije.

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

Uporedite zapis o pristupu na granici s onim što je tablica predvidjela. Zatim spustite tunel i uputite novi zahtjev koji bi trebao biti odbijen; već učitana stranica ili već otvorena veza ne testira ništa. Ako se odbijanje ne pojavi, tačka provođenja nije tamo gdje mislite.

Zadržite autentifikaciju aplikacije nakon mrežnog prijema, jer uredski izlaz i VPN izlaz svaki predstavlja mnogo ljudi i nijedan ne identifikuje pojedinca. Uputa za korisnike ostaje kratka: podignite odobreni tunel, pa pokušajte ponovo. To je ono što drži jedan URL zgodnim dok pravilo o izvoru ostaje odluka, a ne nagađanje.