Vai OpenVPN joprojām bīda vecos maršrutus? Pārbaudiet, ko tas ielādēja

Jūs pievienojat maršrutu, pārstartējat pakalpojumu, pieslēdzaties vēlreiz, un klienta tabula izskatās tieši tāpat kā iepriekš. Var būt patiesas divas dažādas lietas: serveris nav ielādējis jūsu izmaiņas vai klients nav instalējis saņemto. Kopīgs tiem ir tikai simptoms, tāpēc pirmais solis ir noskaidrot, kurš no diviem gadījumiem jums ir.

Tālāk salīdzinājums iet no procesa uz āru, jo process ir vienīgā instance, kas zina, kura datne ir spēkā.

Datne, kuru rediģējāt, un datne, kuru lasa process

Sāciet ar unit un tās radīto komandrindu. systemd resursdatorā systemctl cat openvpn@server izdrukā ExecStart rindu, un instances unit parasti atvasina savu konfigurācijas ceļu no instances nosaukuma, tāpēc dēmons, kas palaists kā openvpn@office, lasa citu datni nekā tas, kas palaists kā openvpn@server. Salīdziniet to ar darbojošā procesa argv. Konfigurācijas pārvaldības rīks pievieno vēl vienu veidu, kā pazaudēt izmaiņas: tas var ierakstīt pareizu datni vietā, kuru unit nekad nemin, un tad veiksmīga izvietošana izskatās kā nekas.

Laikatzīmes to ātri izšķir: ja datne ir jaunāka par procesa starta laiku, process to nevarēja būt lasījis. Maršrutētāja aparātprogrammatūra pievieno trešo gadījumu, jo daudzi modeļi glabā iestatījumus flash atmiņā un startēšanas laikā pārbūvē konfigurāciju, kas datnes rediģēšanu diskā padara par pilnīgi nepareizu slāni.

Ko serveris bīda un ko klients instalē

Uzbīdītajam maršrutam jāiztur divi filtri. Serverī tam jāatrodas ielādētajā konfigurācijā, nevis komentētā blokā vai klientam raksturīgā datnē, kuras nosaukums nesakrīt. Klientā pull ir jābūt iespējotam, un neviens pull-filter nedrīkst izmest šo opciju. Pieslēdzieties ar verbosity 4 un izlasiet uzbīdītās opcijas, par kurām klients ziņo: ja maršruts ir šajā sarakstā, serveris ir izdarījis savu daļu, un klients izvēlas to neinstalēt.

Klientam raksturīgās datnes ir biežs apjukuma avots. Datne, kas nosaukta pēc sertifikāta common name, bīda opcijas tikai tam klientam, un vienas rakstzīmes atšķirība klusi pārtrauc bīdīšanu, bez kļūdas nevienā pusē. Serveris reģistrē common name, ko redzēja savienojuma laikā, tāpēc salīdziniet šo vērtību ar datnes nosaukumu, nevis ar to, ko uzskatāt par klienta nosaukumu.

Uzbīdītais prefikss un atgriešanās maršruts ir dažādas problēmas

Klients, kas apzināti ignorē redirect-gateway, lai saglabātu savu vietējo interneta ceļu, rada otru, nesaistītu robu. Servera zondes sasniedz tuneļa adresi, bet atbildes nekad nenāk, jo atbilde, kas adresēta servera tuneļa IP, tiek maršrutēta caur klienta parasto noklusējuma vārteju. Šeit vainīgs nav uzbīdītais apakštīkla maršruts; trūkst maršruta, kas servera tuneļa tīkla datplūsmu sūta atpakaļ caur tuneļa ierīci.

Šī maršruta pievienošana klientā salabo atbildes uz servera uzsāktajām zondēm. Tas neaizstāj uzbīdīto apakštīkla maršrutu, un otrādi arī ir taisnība, jo abi apraksta pretējus kustības virzienus.

Salīdziniet tabulas abos galos

Pēc jebkādām izmaiņām pieslēdzieties vēlreiz un izlasiet klienta tabulu par uzbīdīto prefiksu un par tuneļa ierīci. Pēc tam pārbaudiet abos virzienos: no klienta uz resursdatoru uzbīdītajā apakštīklā un no šī resursdatora atpakaļ uz klientu. Maršruts, kas pastāv, bet nepārvadā datplūsmu, nozīmē vienu no trim: tālā puse nepārsūta, ugunsmūris nomet plūsmu vai atbildei nav ceļa atpakaļ.

Turiet trīs identifikatorus kopā: konfigurācijas ceļu, unit vai instances nosaukumu un klienta identitāti, ar kuru testējāt.

Šie trīs pārvērš nākamo gadījumu piecu minūšu pārbaudē, nevis vēl vienā izmeklēšanā, un tieši tie ir vajadzīgi kolēģim, kad tunelis kļūst par kāda cita problēmu.

Maršruta problēma, kas pārdzīvo pārstartēšanu, bieži nemaz nav maršrutēšanas problēma; kļūme atrodas augstāk par tabulu, kuru jūs nepārtraukti lasāt.