OpenVPNi lükatud marsruudid pole paigaldatud: ajastus, õigused või poliitika

Server väidab, et lükkas marsruudi, klient väidab, et on ühendatud, ja sihtkoht on ikka kättesaamatu. Täpselt sellise pildi annavad kolm põhjust. Marsruudi lisamine toimus enne, kui seade olemas oli, kliendil puudusid tabeli muutmise õigused või käskis poliitika kliendil lükatud valikuid eirata.

Väljast vaadatuna näevad need identsed välja ja nõuavad erinevaid parandusi. Lugege kliendi logi kohas, kus marsruudi otsus tehakse.

Tõestage, et marsruut puudub, mitte ainult et see on katki

Alustage tõestamisega, et marsruut puudub, mitte et see on katki. Linuxis loetleb ip route show dev tun0, mida klient tunneliseadmele paigaldas. Windowsis näitab route print või Get-NetRoute sama tabeli kujul.

Marsruut, mis on olemas, kuid ei edasta liiklust, on teine probleem. See suunab uurimise edastus- ja tulemüürireeglite juurde, mitte marsruudi paigaldamise juurde.

Ajastus: lisamine toimus enne, kui seade olemas oli

Klient parsib serveri PUSH_REPLY pärast seda, kui juhtkanal on üleval ja kui see on liidese konfigureerinud. Alles siis puudutab ta marsruutimistabelit, kasutades seda mehhanismi, mille platvorm pakub. Linux läheb läbi netlinki; Windows kasutab API-t, mis nõuab kõrgendatud tokenit. Skript või klient, mis lisab marsruute kohe konfiguratsiooni lugedes, võib töötada enne, kui TUN/TAP seade on olemas, ja kernel lükkab lisamise tagasi.

Sama võidujooks selgitab, miks käsitsi trükitud marsruut töötab, aga automaatne mitte: selleks ajaks, kui te seda trükite, on liides juba üleval.

route-delay on just selle juhtumi jaoks ja route-up nimetab skripti, mis käivitub pärast liidese ja marsruutide konfigureerimist. Pange tunneliaadressist sõltuvad marsruudid sellesse haaki, mitte varajasse etappi.

Õigused: kes tohib tabelit muuta

Windowsi marsruutimistabeli muutmiseks on vaja kõrgendatud tokenit. Tavalise kasutaja käivitatud GUI võib seadme aadressi teenuse kaudu seada ja ikkagi mitte suuta marsruuti lisada. Siis näitab logi juurdepääsu keelamise stiilis viga, mitte puuduvat lükkamist.

GUI käivitamine administraatorina või teenusepõhise kliendi kasutamine muudab selle tulemuse. Planeeritud ülesanne, mis käivitab kliendi ilma nõutava tokenita, seda ei muuda.

Kontrollige millise kontoga klient tegelikult töötab, enne kui midagi muudate. Versioon ja teenuserežiim otsustavad, millised põhjused üldse võimalikud on, seega kirjutage mõlemad marsruudi väljundi kõrvale.

Poliitika: lükatud marsruute võib meelega kõrvale heita

route-nopull paneb kliendi eirata marsruute, mida server lükkab, sealhulgas lükatud vaikemarsruuti, samal ajal kui tunneliaadress võetakse endiselt vastu. Lükatud DNS- ja DHCP-valikud jäetakse sama direktiiviga kõrvale. Selline klient ei ole rikkis; ta ootab oma konfiguratsioonis selgesõnalisi marsruudiridu.

route-noexec on teistsugune kontroll: see peatab kliendi täielikult marsruudimuudatusi täitmast. Topoloogia, mida klient ei suuda kaardistada, võib anda sarnase tulemuse, kusjuures marsruut logitakse tagasilükatuna, mitte lisatuna. Lugege logirida, mis otsusest teatab, selle asemel et arvata, milline kolmest kehtib. Seejärel kontrollige tegelikku profiili, sest importija või haldusvahend võib lisada valikuid, mida kasutaja ei ole kunagi muutnud.

Profiil, mis tekstiredaktoris puhtana paistab, võib käitusajal siiski lisatud direktiivi kanda.

Võrrelge lükkamisnimekirja tabeliga

Pärast ühendamist asetage serveri lükkamisnimekiri kliendi tabeli kõrvale. Linuxis on see ip route show dev tun0; Windowsis route print või Get-NetRoute. Kui marsruut puudub, parandage esmalt paigaldus. Kui see on olemas ja liiklus ebaõnnestub, liikuge edasi edastus- ja tulemüüripoliitika juurde.

Kirjutage üles kliendi versioon, konto, millega see töötab, ja see, kas see on teenusepõhine. Need kolm fakti ütlevad järgmisele inimesele, millised põhjused on välistatud.