Nork eduki behar ditu ibilbideak eta DNSa openfortivpn konektatzean?
openfortivpn TLS gaineko PPP da: atebidean onarpena, PPP esteka, esleitutako helbideak, gero ostalariaren ibilbideak eta DNSa. Etapa bakoitza nork daukan erabakitzeak hutsegiteak saihesten ditu.
Lau etapa bata bestearen gainean pilatzen dira lanean ari den openfortivpn saio batean. Bezeroa atebidean autentifikatzen da eta TLS konexio bat hasten du, gero PPP exekutatzen du konexio horren barruan, gero helbide bat eta DNS informazioa jasotzen ditu, eta azkenik ostalariaren ibilbideak eta resolver ezarpenak aplikatzen ditu. Etapa bakoitza bizirik egon daiteke hurrengoa ez dagoen bitartean, eta horregatik da “konektatuta” hitza hain labainkorra laguntza-harietan.
Nahaste handiena kentzen duen erabakia azken etapa nork daukan da. Edo VPN bezeroak berak aplikatzen ditu ostalariaren aldaketak, edo beste osagai batek egiten ditu, eta biak erdibidean nahastea da ibilbideek eta resolver fitxategiek saio desberdinak deskribatzera iristen diren modua.
Konexio bakarra diruditen lau etapa
Lehen etapa onarpena da. izeneko autentifikazio domeinu bat edo erabilera bakarreko kode baten bidez, eta jarraitzeko behar dituen parametroak jasotzen ditu. Bezeroak atebidearekin konektatuta dagoela inprimatzen duenean, horrek esan nahi du TLS garraioa martxan dagoela. Ez du esan nahi PPP-k negoziatu duenik, eta inola ere ez du esan nahi barneko aplikazio bat irisgarri denik.
Bigarren etapa PPP esteka da. Bezeroak PPP prozesu bat abiarazten du tunel gailuaren aurka, eta bi aldeek esteka aukerak eta helbideak negoziatzen dituzte. Horren ondoren bakarrik daki ostalariak saioak zein helbide lokal eta urrun erabiltzen dituen, eta orduan bakarrik du zentzurik tunelera doan ibilbide batek.
Hirugarren etapa informazio hori ostalarian aplikatzea da, eta hemen da garrantzitsua jabetza. Bezeroak ibilbideak gehi ditzake eta resolver konfigurazioa berridatzi, edo atzera egiteko esan dakioke eta biak makina horretan sareaz arduratzen denari utzi. Proiektuaren README fitxategiak erantzukizun bereizi gisa deskribatzen ditu, portaera automatiko bakarraren ordez.
Nork editatzen du bideratze taula
Lehenespenez, bezeroa da jabea. Atebiderako ibilbide bat gehitzen du interfaze fisikoaren bidez, tunelaren parekoarentzako ibilbide bat eta saioak erabil ditzakeen sareetarako ibilbideak, eta gero kentzen ditu prozesua irteten denean. Lehenespen hori erosoa da sare-kudeatzaile bakarra duen eta beste VPN softwarearik ez duen eramangarri batean.
Aukeratu eskualdaketa beste zerbait benetan bideratzearen jabe denean soilik. Sare-kudeatzailearen integrazio batek, kontenedore baten sare-namespace batek edo gune osoko bideratze agente batek badaki agian prefijo berberak instalatzen eta garbitzen. no-routes aukera pasatzeak orduan bi idazlek taula beraren alde borrokatzea eragozten du, eta hori lasterketa bat da, azpisare baten galera tartekatu gisa agertzen dena hutsegite garbi baten ordez.
Gainjartzea da eskualdatzeko bigarren arrazoia. Bultzatutako ibilbideek sare lokalak jada erabiltzen duen prefijo bat badute, bezeroak ezin du gatazka zuretzat konpondu. Norbaitek erabaki behar du prefijo hori tunelaren bidez, esteka fisikoaren bidez edo ibilbide zehatzago baten bidez irisgarri den, eta erabaki hori topologiaren jabe denarena da.
Garbiketa da hirugarrena. Bere ibilbideak kendu aurretik kraskatzen den bezeroak saioa baino gehiago irauten duen zulo beltz bat uzten du, eta hurrengo konexioak duplikatu bat gehi diezaioke gainean. Bideratzearen jabea dena sarrera zaharrak desagertu direla egiaztatzearen jabea ere bada. Egin egiaztapen hori abio-bidearen parte, ez garbiketa urrats aukerakoa.
Nork dauka DNSa eta resolver fitxategia
DNSa ertz zorrotzagoak dituen erabaki bera da. Bezeroak atebideak edo PPP parekoak jakinarazten dituen DNS zerbitzariak onar ditzake eta ostalariaren resolver konfigurazioan idatz ditzake. Makina sinple batean horixe nahi duzu, barne-izenak orduan tunela martxan dagoen bitartean soilik ebazten baitira.
Linux ostalari moderno batean resolverra stub lokal batek kudea dezake, eta resolver fitxategia stub horren bizkarraren atzetik berridazteak zuzena dirudien eta modu ez-koherentean jokatzen duen konfigurazio bat sortzen du. Ostalariak resolver kudeatzaile bat badabil jada, utzi hari DNSaren jabe izaten eta elikatu tunelaren zerbitzariak bere interfaze onartuaren bidez. Bezeroaren no-dns aukera da hor hautaketa zuzena, ez ingurutiko irtenbidea.
DNS zatitua fitxategia nork idazten duenetik bereizitako galdera da. Kontsulta guztiak tunelaren bidez bidaltzea sinplea eta motela da; barne-eremuak soilik haren bidez bidaltzeak domeinu bakoitzeko konfigurazioa eskatzen du, bezero sinple gehienek eskaintzen ez dutena. Erabaki ostalariak zein portaera behar duen bezeroaren resolver aldaketak gaitzen dituzun aurretik. Hemen hautaketa okerra izen-ebazpenaren etena dirudizu tunela bera ondo dagoenean ere.
Pribilegioak, prestutasuna eta eskualdaketa
Tunel gailua sortzeak eta ostalariaren ibilbideak edo resolver egoera editatzeak sare-autoritate handiagoa behar du. Ohiko akatsa da pentsatzea, beraz, dena root gisa exekutatu behar dela, tunela erabiltzen duen nabigatzailea edo aplikazioa barne. Eutsi pribilegiatutako zatiari txiki: bezeroa eta haren konfigurazio fitxategia, administratzaile baten jabetzakoak, erabiltzaile aplikazioek beren kontu arrunta mantentzen duten bitartean.
Prestutasuna kontsumitzaile bakoitzeko definitu behar litzateke. Supervisor batek zerbitzua hasitzat har dezake bezero prozesua martxan dagoenean eta tunel gailua existitzen denean. Babeskopia lan batek VPNa erabilgarritzat har dezake bere biltegiratze muturrak tunelaren bidez erantzuten duenean soilik. Egiaztapen desberdinak dira, eta ahulena helburu sendoagoetarako erabiltzeak oso goiz hasten diren eta tarteka huts egiten duten lanak sortzen ditu. Idatzi hautatutako definizioa, prestutasunaz ados ez dauden supervisor bat eta lan bat gertatzeko zain dagoen laguntza-txartel bat baitira.
Probatu kontratua lau behaketekin: atebide fasea osatzen da, PPP-k helbideak esleitzen ditu, aurreikusitako ibilbidea presente dago, eta barneko ostalari bati egindako eskaerak arrakasta du. Gero gelditu bezeroa eta berretsi horietako bakoitza kenduta edo berrezarrita dagoela. Ostalariak oraindik barne-izenak ebazten baditu edo oraindik ibilbide bat mantentzen badu tunela itxi ondoren, jabetzaren eskualdaketa osatugabea da.