Kas OpenVPN surub endiselt vanu marsruute? Kontrollige, mida see laadis

Lisate marsruudi, taaskäivitate teenuse, ühendute uuesti ja kliendi tabel näeb välja täpselt nagu varem. Tõsi võib olla kaks erinevat asja: server ei laadinud teie muudatust või klient ei paigaldanud seda, mille sai. Ühist on neil vaid sümptom, seega esimene samm on välja selgitada, kumb kahest teil on.

Allolev võrdlus liigub protsessist väljapoole, sest protsess on ainus autoriteet selle kohta, milline fail kehtib.

Fail, mida te muutsite, ja fail, mida protsess loeb

Alustage unit-ist ja käsureast, mille see tekitas. systemd-hostis prindib systemctl cat openvpn@server rea ExecStart ja eksemplari unit tuletab oma konfiguratsioonitee tavaliselt eksemplari nimest, seega openvpn@office-na käivitatud deemon loeb teist faili kui openvpn@server-na käivitatud. Võrrelge seda töötava protsessi argv-ga. Konfiguratsioonihalduse tööriist lisab veel ühe viisi muudatuse kaotamiseks: see võib kirjutada õige faili kohta, mida unit kunagi ei maini, ja siis näeb roheline juurutus välja nagu mitte midagi.

Ajatemplid otsustavad selle kiiresti: kui fail on protsessi algusajast uuem, ei saanud protsess seda lugeda. Ruuteri püsivara lisab kolmanda juhtumi, sest paljud mudelid hoiavad seadeid flash-mälus ja ehitavad konfiguratsiooni käivitamise ajal uuesti üles, mis teeb kettal oleva faili muutmise täiesti valeks kihiks.

Mida server surub ja mida klient paigaldab

Surutud marsruut peab läbima kaks filtrit. Serveris peab see olema laaditud konfiguratsioonis, mitte kommenteeritud plokis ega kliendipõhises failis, mille nimi ei klapi. Kliendis peab pull olema lubatud ja ükski pull-filter ei tohi seda valikut ära visata. Ühenduge verbosity 4-ga ja lugege surutud valikuid, millest klient teatab: kui marsruut on selles loendis, tegi server oma töö ja klient otsustab seda mitte paigaldada.

Kliendipõhised failid on sagedane segaduse allikas. Sertifikaadi common name'i järgi nimetatud fail surub valikuid ainult sellele kliendile ja ühe tähemärgi erinevus peatab surumise vaikselt, ilma veata kummalgi poolel. Server logib common name'i, mida see ühendamisel nägi, seega võrrelge seda väärtust failinimega, mitte sellega, kuidas te arvate klienti kutsutavat.

Surutud prefiks ja tagasitee on erinevad probleemid

Klient, mis jätab meelega tähelepanuta redirect-gateway, et hoida oma kohalikku internetiteed, loob teise, mitteseotud lünga. Serveri sondid jõuavad tunneliaadressini ja vastused ei jõua kunagi kohale, sest serveri tunneli IP-le adresseeritud vastus marsruuditakse kliendi tavalise vaikevärava kaudu. Surutud alamvõrgu marsruut ei ole siin süüdi; puudu on marsruut, mis saadab serveri tunnelivõrgu liikluse tagasi tunneliseadmesse.

Selle marsruudi lisamine kliendis parandab vastused serveri algatatud sondidele. See ei asenda surutud alamvõrgu marsruuti ja ka vastupidi, sest need kaks kirjeldavad vastassuunalisi liikumisi.

Võrrelge tabeleid mõlemas otsas

Pärast igasugust muudatust ühenduge uuesti ja lugege kliendi tabelit surutud prefiksi ja tunneliseadme jaoks. Seejärel testige mõlemas suunas: kliendist surutud alamvõrgu hostini ja sellest hostist tagasi klienti. Marsruut, mis on olemas, kuid ei kanna liiklust, tähendab ühte kolmest: vastaspool ei edasta, tulemüür viskab voolu ära või vastusel pole tagasiteed.

Hoidke kolm identifikaatorit koos: konfiguratsioonitee, unit-i või eksemplari nimi ja kliendi identiteet, millega te testisite.

Need kolm muudavad järgmise juhtumi viie minuti kontrolliks, mitte uueks uurimiseks, ja just neid vajab kolleeg, kui tunnelist saab kellegi teise probleem.

Marsruudiprobleem, mis jääb taaskäivituse järel püsima, ei ole sageli üldse marsruutimisprobleem; viga asub teie pidevalt loetava tabeli kohal.