OpenVPN se gestuurde roetes word nie geïnstalleer nie: tydsberekening, regte of beleid

Die bediener sê hy het die roete gestuur, die kliënt sê hy is verbind, en die bestemming is steeds onbereikbaar. Drie oorsake lewer presies daardie prentjie. Die roetebyvoeging het geloop voordat die toestel bestaan het, die kliënt het die regte ontbreek om die tabel te verander, of ’n beleid het die kliënt aangesê om gestuurde opsies te ignoreer.

Hulle lyk van buite identies en verg verskillende regstellings. Lees die kliëntlogboek by die punt waar die roetebesluit geneem word.

Bewys dat die roete afwesig is, nie net stukkend nie

Begin deur te bewys dat die roete afwesig is eerder as stukkend. Op Linux lys ip route show dev tun0 wat die kliënt op die tonneltoestel geïnstalleer het. Op Windows wys route print of Get-NetRoute dieselfde ding in tabelvorm.

’n Roete wat bestaan maar nie verkeer aanstuur nie, is ’n ander probleem. Dit verskuif die ondersoek na aanstuur- en vuurmuurreëls, nie na roete-installasie nie.

Tydsberekening: die byvoeging het geloop voordat die toestel bestaan het

Die kliënt ontleed die bediener se PUSH_REPLY nadat die beheerkanaal op is en nadat hy die koppelvlak opgestel het. Eers dan raak hy die roetetabel aan, met watter meganisme die platform ook al bied. Linux gaan deur netlink; Windows gebruik ’n API wat ’n verhoogde token nodig het. ’n Skrip of ’n kliënt wat roetes byvoeg sodra hy die konfigurasie lees, kan loop voordat die TUN/TAP-toestel bestaan, en die kernel verwerp die byvoeging.

Dieselfde wedloop verduidelik waarom ’n handgetikte roete werk terwyl die outomatiese een dit nie doen nie: teen die tyd dat jy dit tik, is die koppelvlak op.

route-delay bestaan vir hierdie geval, en route-up wys ’n skrip aan wat loop nadat die koppelvlak en roetes opgestel is. Sit roetes wat van die tonneladres afhang in daardie haak eerder as in ’n vroeë stadium.

Regte: wie mag die tabel verander

Om die Windows-roetetabel te verander, is ’n verhoogde token nodig. ’n GUI wat deur ’n standaardgebruiker begin word, kan die adapteradres deur die diens stel en steeds nie ’n roete byvoeg nie. Die logboek wys dan ’n toegang-geweier-styl fout eerder as ’n ontbrekende stuur.

Om die GUI as administrateur te begin, of om die diensgebaseerde kliënt te gebruik, verander daardie uitkoms. ’n Geskeduleerde taak wat die kliënt sonder die vereiste token begin, doen dit nie.

Kontroleer onder watter rekening die kliënt werklik loop voordat jy iets verander. Die weergawe en die diensmodus bepaal watter oorsake hoegenaamd moontlik is, so teken albei langs die roete-uitset aan.

Beleid: gestuurde roetes kan doelbewus weggegooi word

route-nopull maak dat die kliënt roetes ignoreer wat die bediener stuur, insluitend ’n gestuurde verstekroete, terwyl die tonneladres steeds aanvaar word. Gestuurde DNS- en DHCP-opsies word deur dieselfde richtlijn laat val. So ’n kliënt is nie foutief nie; hy verwag eksplisiete roetelyne in sy eie konfigurasie.

route-noexec is ’n ander beheer: dit stop die kliënt om roeteveranderinge hoegenaamd uit te voer. ’n Topologie wat die kliënt nie kan karteer nie, kan ’n soortgelyke uitkoms lewer, met die roete wat as verwerp eerder as bygevoeg aangeteken word. Lees die logboekreël wat die besluit rapporteer eerder as om te raai watter van die drie van toepassing is. Kontroleer dan die effektiewe profiel, want ’n invoerder of bestuurnutsprogram kan opsies byvoeg wat die gebruiker nooit geredigeer het nie.

’n Profiel wat in ’n teksredigeerder skoon lyk, kan steeds ’n bygevoegde richtlijn tydens looptyd dra.

Vergelyk die stuurlys met die tabel

Nadat jy verbind het, plaas die bediener se stuurlys langs die kliënt se tabel. Op Linux is dit ip route show dev tun0; op Windows, route print of Get-NetRoute. As die roete afwesig is, maak eers die installasie reg. As dit teenwoordig is en verkeer misluk, gaan voort na aanstuur- en vuurmuurbeleid.

Teken die kliëntweergawe, die rekening waaronder dit loop en of dit diensgebaseerd is, aan. Daardie drie feite vertel die volgende persoon watter oorsake uitgesluit is.