Kiu devus posedi itinerojn kaj DNS kiam openfortivpn konektiĝas?

Kvar etapoj stakiĝas unu sur la alia en funkcianta openfortivpn-sesio. La kliento aŭtentikigas sin ĉe la pordego kaj komencas TLS-konekton, poste rulas PPP ene de tiu konekto, poste ricevas adreson kaj DNS-informojn, kaj finfine aplikas gastigajn itinerojn kaj agordojn de la solvilo. Ĉiu etapo povas esti viva dum la sekva ne estas, kaj tial “konektita” estas tiel glitiga vorto en subtenaj fadenoj.

La decido, kiu forigas plej multe da konfuzo, estas kiu posedas la lastan etapon. Aŭ la VPN-kliento mem aplikas la ŝanĝojn al la gastigo, aŭ alia komponanto faras tion, kaj miksi la du duonvoje estas kiel itineroj kaj solvilaj dosieroj finas priskribi malsamajn sesiojn.

Kvar etapoj, kiuj aspektas kiel unu konekto

La unua etapo estas eniro. nomita aŭtentikiga domajno aŭ unufoja kodo, kaj ricevas la parametrojn necesajn por daŭrigi. Kiam la kliento presas, ke ĝi estas konektita al la pordego, tio signifas, ke la TLS-transporto funkcias. Ĝi ne signifas, ke PPP intertraktis, kaj certe ne signifas, ke interna aplikaĵo atingeblas.

La dua etapo estas la PPP-ligilo. La kliento lanĉas PPP-procezon kontraŭ la tunela aparato, kaj la du flankoj intertraktas ligilajn opciojn kaj adresojn. Nur post tio la gastigo scias, kiujn lokajn kaj malproksimajn adresojn la sesio uzas, kaj nur tiam itineron direktitan en la tunelon povas havi sencon.

La tria etapo estas apliki tiun informon al la gastigo, kaj tie posedado gravas. La kliento povas aldoni la itinerojn kaj reskribi la solvilan agordon, aŭ oni povas diri al ĝi retiriĝi kaj lasi ambaŭ al kio ajn alia administras la reton sur tiu maŝino. La README de la projekto priskribas tion kiel apartajn respondecojn anstataŭ unu aŭtomatan konduton.

Kiu redaktas la enkursigan tabelon

Defaŭlte la kliento estas la posedanto. Ĝi aldonas itineron al la pordego tra la fizika interfaco, itineron por la kunulo de la tunelo, kaj itinerojn por la retoj kiujn la sesio rajtas uzi, poste forigas ilin kiam la procezo eliras. Tiu defaŭlto estas oportuna sur tekkomputilo kun unu retadministrilo kaj neniom da alia VPN-programaro.

Elektu la transdonon nur kiam io alia vere posedas enkursigon. Retadministrila integriĝo, uja reta nomspaco aŭ reteja enkursiga agento eble jam scias kiel instali kaj purigi la samajn prefiksojn. Transdoni la opcion no-routes tiam malhelpas du skribantojn batali pri la sama tabelo, kio estas konkurso kiu montriĝas kiel intermita perdo de unu subreto anstataŭ kiel pura fiasko.

Surmeto estas la dua kialo por transdoni. Se la puŝitaj itineroj inkluzivas prefikson kiun la loka reto jam uzas, la kliento ne povas solvi la konflikton por vi. Iu devas decidi ĉu tiu prefikso estas atingebla tra la tunelo, tra la fizika ligilo aŭ tra pli specifa itinero, kaj tiu decido apartenas al kiu ajn posedas la topologion.

Purigado estas la tria. Kliento kiu kraŝas antaŭ forigo de siaj itineroj lasas nigran truon kiu postvivas la sesion, kaj la sekva konekto povas aldoni duplikaton sur ĝin. Kiu posedas enkursigon posedas ankaŭ kontroli ke la malnovaj enskriboj malaperis. Faru tiun kontrolon parto de la ekvojo, ne laŭvola puriga paŝo.

Kiu posedas DNS kaj la solvilan dosieron

DNS estas la sama decido kun pli akraj randoj. La kliento povas akcepti la DNS-servilojn kiujn raportas la pordego aŭ la PPP-kunulo kaj skribi ilin en la solvilan agordon de la gastigo. Sur simpla maŝino tio estas ĝuste kion vi volas, ĉar internaj nomoj tiam solviĝas nur dum la tunelo funkcias.

Sur moderna Linux-gastigo la solvilo povas esti administrata de loka ŝtupo, kaj reskribi la solvilan dosieron malantaŭ la dorso de tiu ŝtupo produktas agordon kiu aspektas ĝusta kaj kondutas sin malkonsekvence. Se la gastigo jam rulas solvilan administrilon, lasu ĝin posedi DNS kaj manĝigu al ĝi la servilojn de la tunelo tra ĝia subtenata interfaco. La opcio no-dns de la kliento estas la ĝusta elekto tie, ne provizora solvo.

Dividita DNS estas aparta demando de kiu skribas la dosieron. Sendi ĉiun demando tra la tunelo estas simpla kaj malrapida; sendi nur internajn zonojn tra ĝi postulas agordon por domajno, kiun plej multaj simplaj klientoj ne provizas. Decidu kiun konduton la gastigo bezonas antaŭ ol ebligi la solvilajn ŝanĝojn de la kliento. Malĝusta elekto ĉi tie aspektas kiel interrompo de nomsolvado eĉ kiam la tunelo mem estas en ordo.

Rajtoj, preteco kaj la transdono

Krei la tunelan aparaton kaj redakti gastigajn itinerojn aŭ solvilan staton bezonas altigitan retan aŭtoritaton. La ordinara eraro estas konkludi ke tial ĉio devas ruli kiel root, inkluzive la retumilon aŭ la aplikaĵon kiu uzas la tunelon. Tenu la privilegian parton malgranda: la kliento kaj ĝia agorda dosiero, posedataj de administranto, dum uzantaj aplikaĵoj konservas sian normalan konton.

Preteco devus esti difinita por ĉiu konsumanto. Kontrolisto povas konsideri la servon komencita kiam la klienta procezo funkcias kaj la tunela aparato ekzistas. Savkopiiga tasko devus konsideri la VPN uzebla nur kiam ĝia stokada finpunkto respondas tra la tunelo. Tiuj estas malsamaj kontroloj, kaj uzi la pli malfortan por la pli forta celo produktas taskojn kiuj komenciĝas tro frue kaj fiaskas intermiten. Skribu la elektitan difinon, ĉar kontrolisto kaj tasko kiuj malkonsentas pri preteco estas subtena bileto atendanta okazi.

Testu la kontrakton per kvar observoj: la pordega fazo finiĝas, PPP asignas adresojn, la celita itinero ĉeestas, kaj peto al interna gastigo sukcesas. Poste haltigu la klienton kaj konfirmu ke ĉiu el tiuj estas forigita aŭ restarigita. Se la gastigo ankoraŭ solvas internajn nomojn aŭ ankoraŭ tenas itineron post kiam la tunelo fermiĝis, la posedtransdono estas nekompleta.