Pwy ddylai fod yn berchen ar lwybrau a DNS pan fydd openfortivpn yn cysylltu?

Mae pedwar cam yn pentyrru ar ei gilydd mewn sesiwn openfortivpn sy'n gweithio. Mae'r cleient yn dilysu wrth y porth ac yn dechrau cysylltiad TLS, yna'n rhedeg PPP o fewn y cysylltiad hwnnw, yna'n derbyn cyfeiriad a gwybodaeth DNS, ac yn olaf yn cymhwyso llwybrau gwesteiwr a gosodiadau datryswr. Gall pob cam fod yn fyw tra nad yw'r nesaf, a dyna pam mae “wedi cysylltu” mor llithrig mewn edafedd cymorth.

Y penderfyniad sy'n tynnu'r rhan fwyaf o'r dryswch yw pwy sy'n berchen ar y cam olaf. Naill ai mae'r cleient VPN yn cymhwyso newidiadau'r gwesteiwr ei hun, neu mae cydran arall yn gwneud hynny, a chymysgu'r ddau hanner ffordd yw sut mae llwybrau a ffeiliau datryswr yn gorffen disgrifio sesiynau gwahanol.

Pedwar cam sy'n edrych fel un cysylltiad

Y cam cyntaf yw derbyniad. parth dilysu a enwir neu god un tro, ac mae'n derbyn y paramedrau sydd eu hangen i barhau. Pan fydd y cleient yn argraffu ei fod wedi cysylltu â'r porth, mae hynny'n golygu bod trafnidiaeth TLS i fyny. Nid yw'n golygu bod PPP wedi trafod, ac yn sicr nid yw'n golygu bod modd cyrraedd rhaglen fewnol.

Yr ail gam yw'r cyswllt PPP. Mae'r cleient yn dechrau proses PPP yn erbyn y ddyfais twnnel, ac mae'r ddwy ochr yn trafod opsiynau cyswllt a chyfeiriadau. Dim ond wedyn y gŵyr y gwesteiwr pa gyfeiriadau lleol ac anghysbell y mae'r sesiwn yn eu defnyddio, a dim ond yna y gall llwybr sy'n pwyntio i'r twnnel wneud synnwyr.

Y trydydd cam yw cymhwyso'r wybodaeth honno i'r gwesteiwr, a dyna lle mae perchnogaeth yn bwysig. Gall y cleient ychwanegu'r llwybrau ac ailysgrifennu ffurfweddiad y datryswr, neu gellir dweud wrtho i sefyll yn ôl a gadael y ddau i beth bynnag arall sy'n rheoli rhwydwaith ar y peiriant hwnnw. Mae README y prosiect yn disgrifio'r rhain fel cyfrifoldebau ar wahân yn hytrach nag un ymddygiad awtomatig.

Pwy sy'n golygu'r tabl llwybro

Yn ddiofyn y cleient yw'r perchennog. Mae'n ychwanegu llwybr tuag at y porth drwy'r rhyngwyneb corfforol, llwybr ar gyfer cymar y twnnel, a llwybrau ar gyfer y rhwydweithiau y caniateir i'r sesiwn eu defnyddio, yna'n eu tynnu pan fydd y broses yn gorffen. Mae'r diofyn hwnnw'n gyfleus ar liniadur ag un rheolwr rhwydwaith a heb feddalwedd VPN arall.

Dewiswch y trosglwyddiad dim ond pan fydd rhywbeth arall wir yn berchen ar lwybro. Efallai bod integreiddiad rheolwr rhwydwaith, gofod enw rhwydwaith cynhwysydd, neu asiant llwybro ar draws y safle eisoes yn gwybod sut i osod a glanhau'r un rhagddodiaid. Mae pasio'r opsiwn no-routes wedyn yn atal dau ysgrifennwr rhag ymladd dros yr un tabl, sef ras sy'n ymddangos fel colli is-rwydwaith yn ysbeidiol yn hytrach nag fel methiant glân.

Gorgyffwrdd yw'r ail reswm dros drosglwyddo. Os yw'r llwybrau a wthir yn cynnwys rhagddodiad y mae'r rhwydwaith lleol eisoes yn ei ddefnyddio, ni all y cleient ddatrys y gwrthdaro drosoch. Rhaid i rywun benderfynu a ellir cyrraedd y rhagddodiad hwnnw drwy'r twnnel, drwy'r cyswllt corfforol, neu drwy lwybr mwy penodol, ac mae'r penderfyniad hwnnw'n perthyn i bwy bynnag sy'n berchen ar y topoleg.

Glanhau yw'r trydydd. Mae cleient sy'n chwalu cyn tynnu ei lwybrau yn gadael twll du sy'n goroesi'r sesiwn, a gall y cysylltiad nesaf ychwanegu copi ar ei ben. Pwy bynnag sy'n berchen ar lwybro sy'n berchen hefyd ar wirio bod yr hen gofnodion wedi mynd. Gwnewch y gwiriad hwnnw'n rhan o'r llwybr cychwyn, nid yn gam glanhau dewisol.

Pwy sy'n berchen ar DNS a ffeil y datryswr

Mae DNS yr un penderfyniad ag ymylon mwy miniog. Gall y cleient dderbyn y gweinyddion DNS y mae'r porth neu gymar PPP yn eu hadrodd a'u hysgrifennu yng nghyfluniad datryswr y gwesteiwr. Ar beiriant syml dyna'n union yr hyn yr ydych ei eisiau, oherwydd dim ond tra bo'r twnnel i fyny y mae enwau mewnol yn datrys wedyn.

Ar westeiwr Linux modern gall stub lleol reoli'r datryswr, ac mae ailysgrifennu ffeil y datryswr y tu ôl i'r stub hwnnw'n cynhyrchu cyfluniad sy'n edrych yn gywir ac yn ymddwyn yn anghyson. Os yw'r gwesteiwr eisoes yn rhedeg rheolwr datryswr, gadewch iddo fod yn berchen ar DNS a bwydwch ef â gweinyddion y twnnel drwy ei ryngwyneb a gefnogir. Opsiwn no-dns y cleient yw'r dewis cywir yno, nid gwaith o amgylch.

Mae DNS hollt yn gwestiwn ar wahân i bwy sy'n ysgrifennu'r ffeil. Mae anfon pob ymholiad drwy'r twnnel yn syml ac yn araf; mae anfon dim ond parthau mewnol drwyddo yn gofyn am gyfluniad fesul parth nad yw'r rhan fwyaf o gleientiaid syml yn ei gynnig. Penderfynwch pa ymddygiad sydd ei angen ar y gwesteiwr cyn galluogi newidiadau datryswr y cleient. Mae dewis anghywir yma'n edrych fel methiant datrys enwau hyd yn oed pan fo'r twnnel ei hun yn iawn.

Breinrydd, parodrwydd, a'r trosglwyddiad

Mae creu'r ddyfais twnnel ac olygu llwybrau gwesteiwr neu gyflwr y datryswr yn gofyn am awdurdod rhwydwaith uwch. Y camgymeriad cyffredin yw casglu bod popeth felly i redeg fel root, gan gynnwys y porwr neu'r rhaglen sy'n defnyddio'r twnnel. Cadwch y rhan freinrydol yn fach: y cleient a'i ffeil gyfluniad, yn berchen i weinyddwr, tra bo rhaglenni defnyddwyr yn cadw eu cyfrif arferol.

Dylid diffinio parodrwydd fesul defnyddiwr. Gall goruchwylydd ystyried bod y gwasanaeth wedi cychwyn pan fydd proses y cleient yn rhedeg ac mae'r ddyfais twnnel yn bodoli. Dylai tasg wrth gefn ystyried bod y VPN yn ddefnyddiadwy dim ond pan fydd ei chyrchfan storio yn ateb drwy'r twnnel. Mae'r rhain yn wiriadau gwahanol, ac mae defnyddio'r un gwannaf at y diben cryfaf yn cynhyrchu tasgau sy'n cychwyn yn rhy gynnar ac yn methu'n ysbeidiol. Ysgrifennwch y diffiniad a ddewiswyd, oherwydd mae goruchwylydd a thasg sy'n anghytuno ar barodrwydd yn docyn cymorth sy'n aros i ddigwydd.

Profwch y contract â phedair arsylwad: mae cam y porth yn cwblhau, mae PPP yn neilltuo cyfeiriadau, mae'r llwybr a fwriadwyd yn bresennol, ac mae cais i westeiwr mewnol yn llwyddo. Yna stopiwch y cleient a chadarnhewch fod pob un o'r rheini wedi'i dynnu neu wedi'i adfer. Os yw'r gwesteiwr yn dal i ddatrys enwau mewnol neu'n dal i ddal llwybr ar ôl i'r twnnel gau, mae'r trosglwyddiad perchnogaeth yn anghyflawn.