Vienas URL biurui ir VPN? Kodėl žlunga leidžiamųjų sąrašo mitas

Prijunkite tunelį, atidarykite tą pačią žymę, ir leidžiama svetainė atsako lygiai taip, kaip atsakydavo iš biuro. Tai prielaida, kuria tyliai remiasi dauguma nuotolinės prieigos planų, ir ji galioja tik tol, kol trys atskiri dalykai vienu metu išlieka teisingi. Nė vienas jų nėra VPN kliento funkcija, ir joks DNS įrašas negali suteikti nė vieno. Kai žymė nepavyksta namuose, naršyklė pateikia vieną bendrą klaidą, nesvarbu, ar priežastis yra trūkstamas maršrutas, nepatvirtintas išėjimo adresas, ar tarpinis serveris, pakeitęs šaltinį, apie kurį praneša. Šių trijų traktavimas kaip vienos problemos yra kelias, kuriuo maža politikos pataisa virsta savaitę trunkančiu leidžiamųjų sąrašų plėtimu.

Dizainas, kuris atlaiko susidūrimą su tikru biuro tinklu, yra siauresnis už prielaidą: aiški trijų eilučių sprendimų lentelė, vienas vykdymo taškas, kurio negalima apeiti, ir neigimo testas, kuris ką nors įrodo. Prielaidos išardymas ateina pirmas, nes viskas po jo priklauso nuo žinojimo, kuris sluoksnis neteisingai pateikia šaltinį.

Mitas: prisijungti nėra maršrutizuoti

Sukuriamas tunelis, ir klientas įdiegia maršrutus tam tikram prefiksų rinkiniui. Tai viskas, ką daro prisijungimas. Ar nesusijusi HTTPS užklausa keliaus per tunelį ir iš kokio viešo adreso atrodys atėjusi, kai atvyks, yra sprendimai, kuriuos vėliau priima kiti komponentai: maršrutų lentelė pasirenka kelią, o išėjimas pasirenka šaltinį.

Štai kodėl biuras ir virtuvės stalas išsiskiria su tuo pačiu nešiojamuoju kompiuteriu, ta pačia naršyklės profilio kopija ir ta pačia žyme. Biure užklausa išeina per prižiūrimą viešą adresą, su kuriuo svetainės operatorius sutiko. Per visą tunelį ji gali išeiti per VPN išėjimą, kuris yra kitas adresas ir, kol kas nors jo nepridės, nepatvirtintas. Per skaidytą tunelį ji gali visai nepatekti į tunelį. Tik du iš tų trijų kelių kada nors buvo susitarimo su svetainės savininku dalis, o trečiasis nėra defektas, kurį reikėtų lopyti papildoma allow eilute.

Trys užklausos būsenos, du patvirtinti išėjimai

Užsirašykite matricą prieš liesdami užkardą, nes lentelė yra dizainas, o taisyklė tėra viena jo įgyvendinimo forma. Žemiau pateikti adresai yra dokumentacijos diapazonai; pakeiskite juos savo prižiūrimomis reikšmėmis ir laikykite ten, kur svetainės savininkas galės juos audituoti.

Būtent vidurinėje eilutėje dauguma šių planų lūžta. Svarbus adresas, kurį mato vykdymo įrenginys, o ne privatus adresas, kurį nešiojamasis kompiuteris laiko tunelio viduje, ir ne jo LAN adresas. Tokia reikšmė kaip 10.8.0.6 viešai svetainei nieko nereiškia, ir 192.168.1.44 taip pat. Tunelio adresas yra tunelio adresavimo detalė, o ne liudijimas, kurį svetainė galėtų patikrinti.

Jei jūsų VPN negali užtikrinti stabilaus, dokumentuoto išėjimo, matrica neturi galiojančios vidurinės eilutės, ir joks leidžiamųjų sąrašų kiekis jos neišras. Sąžiningos parinktys tuo metu yra privati svetainė, pasiekiama per aiškius privačius maršrutus, arba tapatybe besivadovaujantis prieigos vartai priešais programą. Abi turi kitokią sutartį nei viešas leidžiamųjų sąrašas, ir abi lengviau paaiškinti auditoriui nei sąrašą, kuris augo, kol atsitiktinai pradėjo veikti.

Skaitykite šaltinį ten, kur priimamas sprendimas

Uždėkite apribojimą įrenginiui, kuris užbaigia užklausą, ir patvirtinkite, kad joks alternatyvus kilmės kelias jo neaplenkia. Nginx prieigos modulis vertina allow ir deny direktyvas iš eilės, laimi pirmas atitikimas, o iš apgaubiančio bloko paveldėtos taisyklės vis dar galioja location viduje. Siauras allow šalia plataus allow toje pačioje vietoje paprastai reiškia, kad sprendžia platusis. Perskaitykite visą galiojančią to location konfigūraciją prieš redaguodami nors vieną jos eilutę.

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

Už apkrovos balansuotojo ar atvirkštinio tarpinio serverio ši taisyklė mato tarpinį serverį, nebent pasakysite kitaip. Atkurkite kviečiančiojo adresą tik per palaikomą patikimo tarpinio serverio mechanizmą, su aiškiu tarpinių serverių adresų sąrašu. Užklausos antraštė, teigianti patvirtintą adresą, nėra įrodymas, kad kviečiantysis jį turi, o viešame klausytojuje nepatikrinta persiųsta antraštė paverčia leidžiamųjų sąrašą puošmena.

Tada patikrinkite kitą adresų šeimą. Taisyklių rinkinys, apimantis tik IPv4, yra nepilnas sprendimas pagrindinio kompiuterio vardui, kuris atsako ir AAAA, o klientas su veikiančiu IPv6 pasieks tą pačią programą keliu, kurio niekada neperžiūrėjote.

Skaidytas tunelis: užklausa, kuri niekada neįeina

Skaidytas tunelis neša tik savo sąraše esančius prefiksus. Vidiniai biuro potinkliai paprastai patenka į tą sąrašą; vieša svetainė ne. Naršyklė išsprendžia vardą, palygina pasirinktą adresą su maršrutų lentele ir vis tiek randa vietinius numatytuosius vartus priešais.

Taigi užklausa ateina iš naudotojo namų ryšio, yra atmetama, o ataskaita teigia, kad VPN sugedęs, nors tunelis daro būtent tai, kam buvo sukonfigūruotas. Du pataisymai yra teisėti: nukreipkite tą paskirties vietą per tunelį ir leiskite patvirtintam išėjimui ją nešti, arba pripažinkite, kad svetainė pasiekiama tiesiogiai, ir duokite nuotoliniams naudotojams kitą patvirtintą kelią, pavyzdžiui, prieigos vartus. Viešo svetainės leidžiamųjų sąrašo plėtimas, kol į jį atsitiktinai patenka namų adresas, nėra nė vienas iš jų, ir tai pašalina ribą, kurią dizainas turėjo vykdyti. Pirmieji du išlaiko matricą sąžiningą; trečiasis tyliai ištrina iš jos eilutę.

Įrodykite neigimą, tada atkūrimą

Išbandykite užklausa, kuri iš tikrųjų įgyvendina sprendimą, iš kliento, stovinčio kiekvienoje lentelės eilutėje. Pasiekiamumo patikrinimas kokio nors nesusijusio adresą rodančio puslapio atžvilgiu nieko neįrodo, nes ta paskirties vieta gali eiti kitu keliu nei programa.

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

Palyginkite ribos prieigos įrašą su tuo, ką lentelė numatė. Tada nuleiskite tunelį ir atlikite naują užklausą, kuri turėtų būti atmesta; jau įkeltas puslapis ar jau atidarytas ryšys netikrina visiškai nieko. Jei neigimas nepasirodo, vykdymo taškas yra ne ten, kur manote.

Išlaikykite programos autentifikavimą po priėmimo į tinklą, nes biuro išėjimas ir VPN išėjimas kiekvienas atstovauja daugeliui žmonių ir nė vienas neatpažįsta individo. Naudotojams skirta instrukcija lieka trumpa: pakelkite patvirtintą tunelį, tada bandykite dar kartą. Būtent tai išlaiko vieną URL patogų, o šaltinio taisyklė lieka sprendimu, o ne spėjimu.