Labora tekokomputilo sur persona VPN: kio efektive transiras

Kunigi firmaan tekokomputilon al hejma VPN metas ĝin en du lokojn samtempe, kaj la interesa demando estas pli malgranda kaj pli utila ol la alarmiga. Neniu metis Ethernet-kablon inter la oficejo kaj la hejmo, kaj neniu vojo igas la hejman reton etendaĵo de la firmaa subreto. Tio, kio ekzistas, estas unu finpunkto kun aliro al ambaŭ medioj, kaj tri apartaj mekanismoj decidas, kio efektive povas moviĝi inter ili. Trapaŝi tiujn tri ekde la finpunkto eksteren donas respondon, laŭ kiu administranto povas agi anstataŭ debato pri etikedoj.

Komencu ĉe la finpunkto, ne ĉe la reta diagramo

La finpunkto estas la loko, kie ambaŭ konektoj renkontiĝas, do tie komenciĝas la revizio: kiuj procezoj funkcias, kion ili povas atingi, kaj kiu regas ilin. Diagramo, kiu montras du nubojn konektitajn al tekokomputilo, estas preciza kaj senutila, ĉar ĝi implicas ligon, kiu eble ne ekzistas. Anstataŭigu ĝin per listo de la aplikaĵoj, kiuj povas paroli kun ĉiu medio, kaj notu, sub kiu konto ĉiu funkcias. Tiu kadro ankaŭ tenas la revizion proporcia, ĉar tekokomputilo kun du tuneloj ne estas la sama objekto kiel du kunigitaj retoj.

Tiu listo estas la inventaro, el kiu la resto de la revizio laboras. Se ĝi enhavas sinkronigan klienton, retumilan profilon ensalutintan en ambaŭ medioj kaj konstruan agenton kun akreditaĵoj, la revizio jam havas siajn subjektojn.

Tri transirejoj, reviziitaj aparte

Aplikaĵa aliro estas la unua transirejo, kaj ĝi ne postulas ian plusendadon. Retumila langeto, sinkroniga kliento aŭ konstrua agento sur la finpunkto povas legi el rimedo en unu medio kaj sendi datumojn al rimedo en la alia. Tiu kapablo ekzistas sendepende de tio, ĉu la operaciumo plusendas pakaĵojn inter interfacoj, kaj ĝuste tiun mekanismon homoj maltrafas, kiam ili konkludas, ke sen ponto ne estas risko. Legi la liston de aplikaĵoj do estas pli informa ol legi la liston de interfacoj.

Identeco kaj datumoj formas la duan transirejon. Firmaaj akreditaĵoj, sesiaj kuketoj, elŝutitaj dokumentoj kaj administraj rajtoj loĝas sur la finpunkto, kaj aliĝi al alia reto ne malkaŝas ilin per si mem. Tio, kio ŝanĝiĝas, estas la aro da partioj, kiuj povus influi la finpunkton dum ĝi tenas tiujn akreditaĵojn, kaj tio estas demando pri la fidindeco de la persona reto, ne pri enkursigo. Tio estas juĝo, kiun la posedanto de la finpunkto ne povas fari sola, kaj ĝin ne respondas la foresto de plusenda regulo.

Reta plusendado estas la tria kaj la sola, kiu povas transformi la tekokomputilon en transitan aparaton. IP-plusendado, kunhavigo de interreta konekto, prokura servilo aŭ ponto-funkcio povas ĉion fari, kaj ĉiu el ili estas agordo, kiu estas aŭ ŝaltita aŭ ne. Kontrolu tiun staton rekte anstataŭ dedukti ĝin el la ĉeesto de VPN-kliento. Sur administrita maŝino la respondo kutime estas ne, kaj kontroli ĝin konvertas supozon en fakton indan je registrado.

Petu unu rimedon, ne du retojn

Plej multaj realaj postuloj estas pli mallarĝaj ol ili unue ŝajnas: unu konzolo, unu kunhavigita dosierujo, unu interna reta aplikaĵo. Esprimu la postulon tiel kaj lasu la posedanton de la rimedo decidi, ĉu ĝi entute apartenas al ĉi tiu finpunkto. Peto formulita kiel kunigo de du retoj estas malfacile aprobebla kaj facile rifuzebla; peto pri unu nomita servo havas respondon.

Se la respondo estas jes, preferu la plej mallarĝan subtenatan vojon kaj tenu ĝin ene de la ekzistantaj kontroloj de la organizo. Administrita dua profilo aŭ limigita aplikaĵa enskribo konservas monitoradon kaj politikon; konkurenca persona agordo silente anstataŭigas ilin, kaj neniu scias, kiu venkas post la sekva ĝisdatigo.

Inkluzivu la efikojn de DNS kaj vojoj

Nomresolvo ŝanĝiĝas en la momento, kiam dua profilo aktivas. Persona kliento povas trudi sian propran resolvilon, retumilo povas uzi sian propran ĉifritan DNS, kaj politika tabelo povas enkursigi internajn nomojn al alia servilo ol tiu, kiun la firmaa agordo atendas. Neniu el tiuj postulas plusendadon, kaj iu ajn el ili povas sendi internan gastigantan nomon al la malĝusta loko.

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

Kaptu tiujn tri eligojn antaŭ kaj post kiam la dua profilo konektiĝas. La diferenco inter ili estas la efiko, kiu efektive atingas la uzanton, kaj ĝi ofte estas pli granda ol la enkursiga ŝanĝo, kiun priskribas la bileto. Konservu ambaŭ kaptaĵojn, por ke posta revizianto vidu, kio ŝanĝiĝis, ne kio estis intencita.

Kontrolu kaj konservu eliron

Testu la aprobitan aplikaĵon el la reala procezo kaj uzanta kunteksto, ne el administranta ŝelo sur la sama maŝino. Poste konfirmu, ke nerilataj celoj restas neatingeblaj tie, kie la dezajno tion postulas: limo, kiun neniu testis, estas limo, kiun neniu povas pretendi. Malkonekti la personan tunelon devus restarigi la antaŭan staton, kaj tiu restarigo indas je kontrolo, dum iu ankoraŭ rigardas.

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

La gvidado de NIST pri nul-fida arkitekturo utilas ĉi tie, ĉar ĝi forigas retan lokon kiel aŭtomatan fonton de fido, kio estas ĝuste la supozo diskutata. La demando ne estas, ĉu la hejma reto estas fidinda laŭ naturo; ĝi estas, kiu povas atingi kiun rimedon, el kiu finpunkto, tra kiu plenumiga punkto. Respondu tiujn tri, kaj konservu la pruvojn kun la decido.