Wa moat de rûtes en DNS besitte as openfortivpn ferbynt?

Fjouwer fazen steapelje op elkoar yn in wurkjende openfortivpn-sesje. De klient autentisearret him by de poarte en begjint in TLS-ferbining, rint dan PPP binnen dy ferbining, ûntfangt dan in adres en DNS-ynformaasje, en past úteinlik hostrûtes en resolver-ynstellingen ta. Elke faze kin libje wylst de folgjende dat net docht, en dêrom is “ferbûn” sa'n glêd wurd yn stipe-trieds.

It beslút dat de measte betizing fuorthellet, is wa't de lêste faze besit. Of de VPN-klient past de hostferoarings sels ta, of in oare komponint docht it, en it beide healwei mingen is hoe't rûtes en resolver-bestannen úteinlik oare sesjes beskriuwe.

Fjouwer fazen dy't op ien ferbining lykje

De earste faze is tagong. in neamd autentikaasjedomein of in ienmalige koade, en ûntfangt de parameters dy't it nedich hat om troch te gean. As de klient printsje lit dat er mei de poarte ferbûn is, betsjut dat it TLS-transport oan stiet. It betsjut net dat PPP ûnderhannele hat, en it betsjut wis net dat in ynterne applikaasje berikber is.

De twadde faze is de PPP-keppeling. De klient begjint in PPP-proses tsjin it tunnelapparaat, en de beide kanten ûnderhannelje keppelingsopsjes en adressen. Pas dêrnei wit de host hokker lokale en fiere adressen de sesje brûkt, en pas dan kin in rûte nei de tunnel ta sin meitsje.

De tredde faze is dy ynformaasje op 'e host tapasse, en dêr is eigendom fan belang. De klient kin de rûtes tafoegje en de resolver-konfiguraasje oerskriuwe, of him kin sein wurde om efterút te gean en beide oer te litten oan wat oars it netwurk op dy masine beheart. It README fan it projekt beskriuwt dizze as aparte ferantwurdlikheden ynstee fan ien automatysk gedrach.

Wa't de routingstabel bewurket

By standert is de klient de eigener. Hy foeget in rûte nei de poarte ta fia de fysike ynterface, in rûte foar de peer fan de tunnel, en rûtes foar de netwurken dy't de sesje brûke mei, en ferwideret se dan as it proses ôfslút. Dy standert is handich op in laptop mei ien netwurkbehearder en gjin oare VPN-software.

Kies de oerdracht allinnich as eat oars echt routing besit. In yntegraasje fan in netwurkbehearder, in netwurknammromte fan in container of in routingagent foar de hiele side wit miskien al hoe't deselde foarheaksels ynstallearre en skjinfage wurde. It trochjaan fan de no-routes-opsje foarkomt dan dat twa skriuwers om deselde tabel fjochtsje, wat in wedstriid is dy't him sjen lit as tuskentiidich ferlies fan ien subnet ynstee fan in skjinne flater.

Oerlaap is de twadde reden om oer te dragen. As de trochskode rûtes in foarheaksel befetsje dat it lokale netwurk al brûkt, kin de klient it konflikt net foar jo oplosse. Immen moat beslute oft dat foarheaksel berikber is fia de tunnel, fia de fysike keppeling of fia in spesifiker rûte, en dat beslút heart by wa't de topology besit.

Opromme is de tredde. In klient dy't crasht foardat er syn rûtes fuorthellet, lit in swart gat efter dat de sesje oerlibbet, en de folgjende ferbining kin der in duplikaat boppe-op sette. Wa't routing besit, besit ek it kontrolearjen dat de âlde ynfieringen fuort binne. Meitsje dy kontrôle diel fan it opstartpaad, net in opsjonele opromstap.

Wa't DNS en it resolver-bestân besit

DNS is itselde beslút mei skerpere rânen. De klient kin de DNS-tsjinners akseptearje dy't de poarte of de PPP-peer rapportearret en se yn 'e resolver-konfiguraasje fan de host skriuwe. Op in ienfâldige masine is dat krekt wat jo wolle, want ynterne nammen losse dan allinnich op wylst de tunnel oan is.

Op in moderne Linux-host kin de resolver beheard wurde troch in lokale stub, en it oerskriuwen fan it resolver-bestân efter de rêch fan dy stub leveret in konfiguraasje op dy't korrekt liket en net konsekwint gedraacht. As de host al in resolverbehearder rint, lit dy dan DNS besitte en fieder him de tsjinners fan de tunnel fia syn stipe ynterface. De no-dns-opsje fan 'e klient is dêr de krekte kar, net in omwei.

Split-DNS is in aparte fraach fan wa't it bestân skriuwt. Eltse query troch de tunnel stjoere is ienfâldich en stadich; allinnich ynterne sônes der troch stjoere freget per-domein-konfiguraasje dy't de measte ienfâldige klanten net biede. Beslút hokker gedrach de host nedich hat foardat jo de resolver-feroarings fan 'e klient ynskeakelje. In ferkearde kar hjir liket op in nammoplossing útfallen sels as de tunnel sels goed is.

Privileezje, gereedheid en de oerdracht

It meitsjen fan it tunnelapparaat en it bewurkjen fan hostrûtes of resolver-steat freget ferhege netwurksaazje. De gewoane flater is te konkludearjen dat dêrom alles as root rinne moat, ynklusyf de browser of de applikaasje dy't de tunnel brûkt. Hâld it privilezearre part lyts: de klient en syn konfiguraasjebestân, eigendom fan in behearder, wylst brûkersapplikaasjes har normale akkount hâlde.

Gereedheid moat per ferbrûker definiearre wurde. In supervisor kin de tsjinst as begûn beskôgje as it kliïntproses rint en it tunnelapparaat bestiet. In backupsyklus moat de VPN pas brûkber beskôgje as syn opslach-einpunt fia de tunnel antwurdet. Dat binne ferskillende kontrôles, en it swakkere brûke foar it sterkere doel leveret taken op dy't te betiid begjinne en tuskentiidich mislearje. Skriuw de keazen definysje del, want in supervisor en in taak dy't it net iens binne oer gereedheid binne in stipekaart dy't wachtet om te barren.

Test it kontrakt mei fjouwer observaasjes: de poartefaze foltôget, PPP wiist adressen ta, de bedoelde rûte is oanwêzich, en in fersyk nei in ynterne host slagget. Stop dan de klient en befêstigje dat elk fan dy dingen fuorthelle of restaurearre is. As de host nei it sluten fan 'e tunnel noch ynterne nammen oplost of noch in rûte hâldt, is de eigendomsoerdracht net folslein.