Puŝitaj vojoj de OpenVPN ne instalitaj: tempigado, rajtoj aŭ politiko

La servilo diras, ke ĝi puŝis la vojon, la kliento diras, ke ĝi estas konektita, kaj la celo restas neatingebla. Tri kaŭzoj produktas ĝuste tiun bildon. La aldono de la vojo kuris antaŭ ol la aparato ekzistis, la kliento mankis rajtojn ŝanĝi la tabelon, aŭ politiko ordonis al la kliento ignori puŝitajn opciojn.

De ekstere ili aspektas identaj kaj postulas malsamajn riparojn. Legu la klientan protokolon ĉe la punkto, kie oni decidas pri la vojo.

Pruvu, ke la vojo mankas, ne nur ke ĝi estas rompita

Komencu pruvante, ke la vojo mankas anstataŭ esti rompita. En Linux ip route show dev tun0 listigas, kion la kliento instalis sur la tunela aparato. En Windows route print aŭ Get-NetRoute montras la samon en tabela formo.

Vojo, kiu ekzistas sed ne plusendas trafikon, estas alia problemo. Tio movas la esploron al plusendaj kaj fajroŝirmilaj reguloj, ne al voja instalado.

Tempigado: la aldono kuris antaŭ ol la aparato ekzistis

La kliento analizas la PUSH_REPLY de la servilo post kiam la regada kanalo estas supren kaj post kiam ĝi agordis la interfacon. Nur tiam ĝi tuŝas la vojigan tabelon, uzante kian ajn mekanismon la platformo provizas. Linux iras tra netlink; Windows uzas API-on, kiu bezonas altigitan ĵetonon. Skripto aŭ kliento, kiu aldonas vojojn tuj post legado de la agordo, povas kuri antaŭ ol la aparato TUN/TAP ekzistas, kaj la kerno malakceptas la aldonon.

La sama konkurso klarigas, kial permane tajpita vojo funkcias dum la aŭtomata ne: kiam vi tajpas ĝin, la interfaco jam estas supre.

route-delay ekzistas por ĉi tiu kazo, kaj route-up nomas skripton, kiu kuras post kiam la interfaco kaj vojoj estas agorditaj. Metu vojojn dependajn de la tunela adreso en tiun hokon anstataŭ en fruan fazon.

Rajtoj: kiu rajtas ŝanĝi la tabelon

Ŝanĝi la vojigan tabelon de Windows bezonas altigitan ĵetonon. GUI startigita de ordinara uzanto povas agordi la adaptilan adreson per la servo kaj tamen ne povi aldoni vojon. La protokolo tiam montras eraron de tipo aliro malpermesita anstataŭ mankanta puŝo.

Startigi la GUI kiel administranto, aŭ uzi la serv-bazan klienton, ŝanĝas tiun rezulton. Planita tasko, kiu lanĉas la klienton sen la bezonata ĵetono, ne faras tion.

Kontrolu per kiu konto la kliento efektive kuras antaŭ ol ŝanĝi ion. La versio kaj la serva reĝimo determinas, kiuj kaŭzoj eĉ eblas, do notu ambaŭ apud la eligo de la vojo.

Politiko: puŝitaj vojoj povas esti intence forĵetitaj

route-nopull igas la klienton ignori vojojn, kiujn la servilo puŝas, inkluzive de puŝita implicita vojo, dum la tunela adreso ankoraŭ akceptiĝas. Puŝitaj DNS kaj DHCP opcioj estas forĵetitaj de la sama direktivo. Tia kliento ne estas difektita; ĝi atendas eksplicitajn vojajn liniojn en sia propra agordo.

route-noexec estas alia kontrolo: ĝi tute haltigas la klienton plenumi vojajn ŝanĝojn. Topologio, kiun la kliento ne povas mapi, povas doni similan rezulton, kaj la vojo registriĝas kiel malakceptita anstataŭ aldonita. Legu la protokolan linion, kiu raportas la decidon, anstataŭ diveni, kiu el la tri validas. Poste kontrolu la efektivan profilon, ĉar importantilo aŭ administra ilo povas aldoni opciojn, kiujn la uzanto neniam redaktis.

Profilo, kiu aspektas pura en tekstredaktilo, povas tamen porti aldonitan direktivon dum plenumado.

Komparu la puŝliston kun la tabelo

Post konekto, metu la puŝliston de la servilo apud la tabelon de la kliento. En Linux tio estas ip route show dev tun0; en Windows route print aŭ Get-NetRoute. Se la vojo mankas, unue riparu la instaladon. Se ĝi ekzistas kaj trafiko malsukcesas, transiru al plusenda kaj fajroŝirmila politiko.

Notu la klientan version, la konton per kiu ĝi kuras, kaj ĉu ĝi estas serv-baza. Tiuj tri faktoj diras al la sekva persono, kiuj kaŭzoj estis ekskluditaj.