Viens URL birojam un VPN? Kāpēc atļauto saraksta mīts izgāžas
VPN savienojums nemaina adresi, ko redz atļautā vietne. Pārbaudiet faktisko izeju, uzticamā starpniekservera lēcienu un IPv6 ceļu, pirms pievienojat URL.
Pievienojiet tuneli, atveriet to pašu grāmatzīmi, un atļautā vietne atbild tieši tā, kā tā darīja no biroja. Šis ir pieņēmums, uz kura klusi balstās lielākā daļa attālinātās piekļuves plānu, un tas ir spēkā tikai tik ilgi, kamēr trīs atsevišķas lietas vienlaikus paliek patiesas. Neviena no tām nav VPN klienta funkcija, un neviens DNS ieraksts nevar nodrošināt nevienu no tām. Kad grāmatzīme mājās neizdodas, pārlūks dod vienu vispārīgu kļūdu, lai vai cēlonis būtu trūkstošs maršruts, neapstiprināta izejas adrese vai starpniekserveris, kas aizstāja avotu, par kuru tas ziņo. Šo trīs uztvert kā vienu problēmu ir ceļš, kā neliels politikas labojums pārvēršas atļauto sarakstu paplašināšanas nedēļā.
Dizains, kas iztur saskari ar īstu biroja tīklu, ir šaurāks par pieņēmumu: skaidra trīs rindu lēmumu tabula, viens izpildes punkts, kuru nevar apiet, un nolieguma tests, kas kaut ko pierāda. Pieņēmuma demontāža nāk pirmā, jo viss pēc tam ir atkarīgs no zināšanas, kura kārta avotu attēlo nepareizi.
Mīts: pieslēgties nav maršrutēt
Tiek izveidots tunelis, un klients instalē maršrutus noteiktai prefiksu kopai. Tas ir viss, ko dara pieslēgšanās. Vai nesaistīts HTTPS pieprasījums ceļos pa tuneli un no kādas publiskas adreses tas izskatīsies nākam, kad ieradīsies, ir lēmumi, ko vēlāk pieņem citas komponentes: maršrutu tabula izvēlas ceļu, un izeja izvēlas avotu.
Tāpēc birojs un virtuves galds atšķiras ar to pašu klēpjdatoru, to pašu pārlūka profilu un to pašu grāmatzīmi. Birojā pieprasījums iziet caur uzturētu publisku adresi, kurai vietnes operators ir piekritis. Caur pilnu tuneli tas var iziet caur VPN izeju, kas ir cita adrese un, kamēr kāds to nav pievienojis, neapstiprināta. Caur sadalītu tuneli tas var vispār neieiet tunelī. Tikai divi no šiem trim ceļiem kādreiz bija daļa no vienošanās ar vietnes īpašnieku, un trešais nav defekts, kas jālabo ar papildu allow rindu.
Trīs pieprasījuma stāvokļi, divas apstiprinātas izejas
Pierakstiet matricu, pirms aiztiekat ugunsmūri, jo tabula ir dizains, un noteikums ir tikai viens tā īstenojums. Zemāk esošās adreses ir dokumentācijas diapazoni; aizstājiet tās ar savām uzturētajām vērtībām un glabājiet tur, kur vietnes īpašnieks var tās auditēt.
| 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 |
Vidējā rinda ir vieta, kur lielākā daļa šo plānu lūzt. Svarīga ir adrese, ko redz izpildes ierīce, nevis privātā adrese, ko klēpjdators tur tuneļa iekšpusē, un nevis tā LAN adrese. Tāda vērtība kā 10.8.0.6 publiskai vietnei neko nenozīmē, un 192.168.1.44 arī ne. Tuneļa adrese ir tuneļa adresēšanas detaļa, nevis apliecinājums, ko vietne varētu pārbaudīt.
Ja jūsu VPN nevar nodrošināt stabilu, dokumentētu izeju, matricai nav derīgas vidējās rindas, un neviens atļauto sarakstu daudzums to neizdomās. Godīgās iespējas tajā brīdī ir privāta vietne, kas sasniedzama pa skaidriem privātiem maršrutiem, vai identitāti apzināta piekļuves vārteja lietotnes priekšā. Abām ir citāds līgums nekā publiskam atļauto sarakstam, un abas ir vieglāk izskaidrot auditoram nekā saraksts, kas auga, līdz nejauši sāka darboties.
Lasiet avotu tur, kur tiek pieņemts lēmums
Uzlieciet ierobežojumu ierīcei, kas pabeidz pieprasījumu, un apstipriniet, ka neviens alternatīvs izcelsmes ceļš to neapiet. Nginx piekļuves modulis novērtē allow un deny direktīvas pēc kārtas, uzvar pirmā atbilstība, un no aptverošā bloka mantotie noteikumi joprojām ir spēkā location iekšpusē. Šaurs allow blakus plašam allow tajā pašā vietā parasti nozīmē, ka izšķir plašais. Izlasiet visu spēkā esošo šī location konfigurāciju, pirms rediģējat kaut vienu tās rindu.
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;
}
}
Aiz slodzes balansētāja vai apgrieztā starpniekservera šis noteikums redz starpniekserveri, ja vien nepasakāt citādi. Atjaunojiet zvanītāja adresi tikai ar atbalstīto uzticamā starpniekservera mehānismu, ar skaidru starpniekserveru adrešu sarakstu. Pieprasījuma galvene, kas apgalvo apstiprinātu adresi, nav pierādījums, ka zvanītājam tā pieder, un publiskā klausītājā nevalidēta pārsūtītā galvene pārvērš atļauto sarakstu par rotājumu.
Pēc tam pārbaudiet otru adrešu saimi. Noteikumu kopa, kas aptver tikai IPv4, ir nepilnīgs lēmums resursdatora nosaukumam, kas atbild arī uz AAAA, un klients ar strādājošu IPv6 sasniegs to pašu lietotni pa ceļu, kuru jūs nekad neesat pārskatījis.
Sadalīts tunelis: pieprasījums, kas nekad neieiet
Sadalīts tunelis pārvadā tikai prefiksus savā sarakstā. Biroja iekšējie apakštīkli parasti nokļūst šajā sarakstā; publiska vietne ne. Pārlūks atrisina vārdu, salīdzina izvēlēto adresi ar maršrutu tabulu un tomēr atrod sev priekšā vietējo noklusējuma vārteju.
Tā pieprasījums nāk no lietotāja mājas savienojuma, tiek noraidīts, un pārskats vēsta, ka VPN ir salūzis, kamēr tunelis dara tieši to, kam tas tika konfigurēts. Divi labojumi ir likumīgi: novirziet šo galamērķi caur tuneli un ļaujiet apstiprinātajai izejai to nest, vai pieņemiet, ka vietne tiek sasniegta tieši, un dodiet attālinātajiem lietotājiem citu apstiprinātu ceļu, piemēram, piekļuves vārteju. Vietnes publiskā atļauto saraksta paplašināšana, līdz tajā nejauši iekļūst mājas adrese, nav neviens no tiem, un tā noņem robežu, kas dizainam bija jāizpilda. Pirmie divi uztur matricu godīgu; trešais klusi izdzēš no tās rindu.
Pierādiet noliegumu, tad atjaunošanu
Pārbaudiet ar pieprasījumu, kas īsteno īsto lēmumu, no klienta, kas stāv katrā tabulas rindā. Sasniedzamības pārbaude pret kādu nesaistītu adresi rādošu lapu neko nepierāda, jo šis galamērķis var iet citā ceļā nekā lietotne.
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/'
Salīdziniet robežas piekļuves ierakstu ar to, ko tabula paredzēja. Pēc tam nolaidiet tuneli un izveidojiet jaunu pieprasījumu, kas būtu jānoraida; jau ielādēta lapa vai jau atvērts savienojums nepārbauda itin neko. Ja noliegums neparādās, izpildes punkts nav tur, kur jūs domājat.
Saglabājiet lietotnes autentifikāciju pēc uzņemšanas tīklā, jo biroja izeja un VPN izeja katra pārstāv daudz cilvēku, un neviena neidentificē indivīdu. Norādījums lietotājiem paliek īss: paceliet apstiprināto tuneli, tad mēģiniet vēlreiz. Tas ir tas, kas uztur vienu URL ērtu, kamēr avota noteikums paliek lēmums, nevis minējums.