OpenVPN bliuwt âlde rûtes triuwe? Kontrolearje wat it laden hat

Jo foegje in rûte ta, starte de tsjinst opnij, meitsje fannijs ferbining, en de tabel fan 'e klant sjocht der krekt itselde út as earder. Twa ferskillende dingen kinne wier wêze: de server hat jo bewurking nea laden, of de klant hat nea ynstallearre wat er krige. Se hawwe neat mienskiplik behalve it symptoom, dus de earste stap is útfine hokker fan de twa jo hawwe.

De ferliking hjirûnder giet fan it proses nei bûten, om't it proses de iennichste autoriteit is oer hokker bestân jildt.

It bestân dat jo bewurke hawwe en it bestân dat it proses lêst

Begjin by de unit en de kommando-line dy't dy produsearre hat. Op in systemd-host printsjelet systemctl cat openvpn@server de line ExecStart, en in eksimplaar-unit liedt syn konfiguraasjepaad ornaris fan 'e eksimplaarnamme ôf, sadat in daemon dy't as openvpn@office start is in oar bestân lêst as ien dy't as openvpn@server start is. Ferlykje dat mei de argv fan it rinnende proses. In konfiguraasjebehear-ark foeget noch in manier ta om de bewurking kwyt te reitsjen: it kin in korrekt bestân skriuwe op in plak dat de unit nea neamt, en dan sjocht in griene útrulling derút as neat.

Tiidstimpels beklinke it fluch: as it bestân nijer is as de starttiid fan it proses, koe it proses it net lêzen hawwe. Router-firmware foeget in tredde gefal ta, om't in protte modellen har ynstellings yn flash bewarje en de konfiguraasje by it opstarten wer opbouwe, wat in bestânsbewurking op skiif folslein de ferkearde laach makket.

Wat de server trúnt en wat de klant ynstallearret

In trúnde rûte moat twa filters oerlibje. Op 'e server moat dy yn 'e laden konfiguraasje stean, net yn in kommentearre blok of yn in klantspezifyk bestân wêrfan de namme net past. Op 'e klant moat pull oan stean en gjin pull-filter mei de opsje fuortsmite. Meitsje ferbining mei verbosity 4 en lês de trúnde opsjes dy't de klant rapporteart: as de rûte yn dy list stiet, hat de server syn wurk dien en kiest de klant om dy net te ynstallearjen.

Klantspezifike bestannen binne in faak foarkommende boarne fan betizing. In bestân dat nei de common name fan it sertifikaat neamd is, trúnt opsjes allinnich nei dy klant, en in ferskil fan ien teken stopet it triuwen stil, sûnder flater oan ien fan beide kanten. De server logt de common name dy't er by ferbining seach, dus ferlykje dy wearde mei de bestânsnamme, net mei wat jo tinke dat de klant hjit.

It trúnde foarheaksel en de weromrûte binne ferskillende problemen

In klant dy't redirect-gateway mei opset negearret om syn lokale internetpaad te hâlden, makket in twadde, net besibbe gat. De probes fan 'e server berikke it tuneladres en de antwurden komme nea oan, om't in antwurd oan it tunel-IP fan 'e server rûte wurdt fia it gewoane standertgateway fan 'e klant. De trúnde subnetrûte is hjir net skuldich; wat ûntbrekt is in rûte dy't ferkear foar it tunelnetwurk fan 'e server werom troch it tunelapparaat stjoert.

Dy rûte op 'e klant taheakje makket antwurden op probes dy't de server begjint, klear. It ferfangt de trúnde subnetrûte net, en it omkearde jildt ek, om't de beide tsjinoerstelde reisrjochtingen beskriuwe.

Ferlykje de tabellen oan beide kanten

Meitsje nei elke wiziging fannijs ferbining en lês de tabel fan 'e klant foar it trúnde foarheaksel en foar it tunelapparaat. Testje dan yn beide rjochtingen: fan 'e klant nei in host op it trúnde subnet, en fan dy host werom nei de klant. In rûte dy't bestiet mar gjin ferkear draacht, betsjut ien fan trije dingen: de oare kant stjoert net troch, in firewall smyt de stream fuort, of it antwurd hat gjin paad werom.

Hâld trije identifikaasjes byinoar: it konfiguraasjepaad, de namme fan 'e unit of it eksimplaar, en de klantidentiteit dêr't jo mei testen.

Dy trije meitsje fan it folgjende foarfal in kontrôle fan fiif minuten ynstee fan in nij ûndersyk, en se binne wat in kollega nedich hat as de tunel it probleem fan in oar wurdt.

In rûteprobleem dat in werstart oerlibbet is faak hielendal gjin rûteprobleem; de fout sit boppe de tabel dy't jo hieltyd lêze.