Kdo naj bi imel v lasti poti in DNS, ko se openfortivpn poveže?

V delujoči seji openfortivpn se štiri stopnje nalagajo druga na drugo. Odjemalec se preveri na prehodu in začne povezavo TLS, nato v tej povezavi zažene PPP, nato prejme naslov in podatke DNS ter nazadnje uporabi poti gostitelja in nastavitve razreševalnika. Vsaka stopnja je lahko živa, medtem ko naslednja ni, in zato je »povezano« tako spolzka beseda v nitih podpore.

Odločitev, ki odpravi večino zmede, je, kdo ima v lasti zadnjo stopnjo. Ali odjemalec VPN sam uporabi spremembe gostitelja, ali to stori druga komponenta, mešanje obojega na pol poti pa je razlog, da poti in datoteke razreševalnika na koncu opisujejo različne seje.

Štiri stopnje, ki so videti kot ena povezava

Prva stopnja je sprejem. imenovana domena preverjanja ali enkratno kodo in prejme parametre, potrebne za nadaljevanje. Ko odjemalec izpiše, da je povezan s prehodom, to pomeni, da je transport TLS aktiven. Ne pomeni, da se je PPP dogovoril, in zagotovo ne pomeni, da je notranja aplikacija dosegljiva.

Druga stopnja je povezava PPP. Odjemalec zažene proces PPP proti tunelski napravi in obe strani se dogovorita o možnostih povezave in naslovih. Šele po tem gostitelj ve, katere lokalne in oddaljene naslove uporablja seja, in šele takrat ima pot v tunel smisel.

Tretja stopnja je uporaba teh podatkov na gostitelju, in tu je lastništvo pomembno. Odjemalec lahko doda poti in prepiše konfiguracijo razreševalnika, ali pa mu naročimo, naj se umakne in oboje prepusti temu, kar sicer upravlja omrežje na tem stroju. README projekta to opisuje kot ločene odgovornosti, ne kot eno samodejno vedenje.

Kdo ureja usmerjevalno tabelo

Privzeto je lastnik odjemalec. Doda pot do prehoda prek fizičnega vmesnika, pot za partnerja tunela in poti za omrežja, ki jih seja sme uporabljati, nato pa jih ob izhodu procesa odstrani. Ta privzeta vrednost je priročna na prenosniku z enim upraviteljem omrežja in brez druge programske opreme VPN.

Prenos izberite le, ko usmerjanje resnično pripada nečemu drugemu. Integracija z upraviteljem omrežja, omrežni imenski prostor vsebnika ali agent za usmerjanje celotnega mesta morda že vedo, kako namestiti in počistiti iste predpone. Posredovanje možnosti no-routes takrat prepreči dvema piscema, da bi se borila za isto tabelo, kar je tekma, ki se kaže kot občasna izguba enega podomrežja, ne pa kot čista napaka.

Prekrivanje je drugi razlog za prenos. Če potisnjene poti vsebujejo predpono, ki jo lokalno omrežje že uporablja, odjemalec ne more rešiti konflikta namesto vas. Nekdo mora odločiti, ali je ta predpona dosegljiva prek tunela, prek fizične povezave ali prek bolj specifične poti, in ta odločitev pripada tistemu, ki ima v lasti topologijo.

Čiščenje je tretje. Odjemalec, ki se sesuje, preden odstrani svoje poti, pusti črno luknjo, ki preživi sejo, in naslednja povezava lahko nanjo doda dvojnik. Kdor ima v lasti usmerjanje, ima v lasti tudi preverjanje, da so stari vnosi izginili. To preverjanje naredite del zagonske poti, ne izbirni korak čiščenja.

Kdo ima v lasti DNS in datoteko razreševalnika

DNS je enaka odločitev z ostrejšimi robovi. Odjemalec lahko sprejme strežnike DNS, ki jih sporoča prehod ali partner PPP, in jih zapiše v konfiguracijo razreševalnika gostitelja. Na preprostem stroju je to natanko tisto, kar želite, saj se notranja imena takrat razrešujejo le, dokler je tunel aktiven.

Na sodobnem gostitelju Linux lahko razreševalnik upravlja lokalni stub, prepisovanje datoteke razreševalnika za hrbtom tega stub pa ustvari konfiguracijo, ki je videti pravilna in se vede nedosledno. Če gostitelj že izvaja upravitelj razreševalnika, mu dovolite, da ima v lasti DNS, in mu posredujte strežnike tunela prek njegovega podprtega vmesnika. Možnost no-dns odjemalca je tam prava izbira, ne obhod.

Razdeljeni DNS je ločeno vprašanje od tega, kdo piše datoteko. Pošiljanje vsake poizvedbe skozi tunel je preprosto in počasno; pošiljanje samo notranjih območij skozenj zahteva konfiguracijo za vsako domeno, ki je večina preprostih odjemalcev ne ponuja. Odločite se, kakšno vedenje gostitelj potrebuje, preden omogočite spremembe razreševalnika odjemalca. Napačna izbira tukaj je videti kot izpad razreševanja imen, tudi ko je tunel sam v redu.

Privilegiji, pripravljenost in prenos

Ustvarjanje tunelske naprave in urejanje poti gostitelja ali stanja razreševalnika zahteva povišano omrežno pooblastilo. Pogosta napaka je sklepanje, da mora zato vse teči kot root, vključno z brskalnikom ali aplikacijo, ki uporablja tunel. Privilegirani del naj bo majhen: odjemalec in njegova konfiguracijska datoteka, v lasti skrbnika, medtem ko uporabniške aplikacije obdržijo običajen račun.

Pripravljenost je treba določiti za vsakega porabnika. Nadzornik lahko šteje storitev za zagnano, ko proces odjemalca teče in tunelska naprava obstaja. Varnostno kopiranje naj šteje VPN za uporabnega šele, ko se njegova končna točka shrambe odzove skozi tunel. To so različna preverjanja, uporaba šibkejšega za močnejši namen pa ustvari opravila, ki se začnejo prezgodaj in občasno spodletijo. Zapišite izbrano definicijo, saj sta nadzornik in opravilo, ki se ne strinjata o pripravljenosti, zahtevek za podporo, ki čaka, da se zgodi.

Preizkusite pogodbo s štirimi opažanji: faza prehoda se zaključi, PPP dodeli naslove, predvidena pot je prisotna in zahteva do notranjega gostitelja uspe. Nato ustavite odjemalca in potrdite, da je vsako od tega odstranjeno ali obnovljeno. Če gostitelj po zaprtju tunela še vedno razrešuje notranja imena ali še vedno drži pot, prenos lastništva ni popoln.