OpenVPN atslēdzas pēc DHCP atjauninājuma: saglabājiet galapunkta maršrutu

Tunelis savienojas, tad nomas atjauninājums piekļuves saitē to nogalina, un žurnāls vaino taimautu, nevis maršrutu. VPN konfigurācijā nekas nav mainījies, un tā ir norāde: kaut kas ārpus tās ir mainījies. DHCP notikums pārrakstīja adresi vai vārteju, un maršruts uz resursdatoru, kas turēja tuneļa galapunktu sasniedzamu, tagad rāda uz nākamo lēcienu, kura vairs nav. Tā ir īpašumtiesību problēma pirms maršrutēšanas problēmas.

Salīdziniet simptomu ar puslielajiem noklusējuma maršrutiem

Ar redirect-gateway def1 OpenVPN instalē 0.0.0.0/1 un 128.0.0.0/1, nevis aizstāj noklusējuma maršrutu. Kopā šie divi nosedz visu adrešu telpu, un tie pārspēj 0.0.0.0/0 tikai ar prefiksa garumu. Tāpēc jebkurš galamērķis bez konkrētākas atbilstības nonāk tunelī.

Galapunktam vajadzīgs izņēmums. OpenVPN pievieno maršrutu uz servera adresi caur sākotnējo piekļuves vārteju pirms puslielo maršrutu ievades, lai iekapsulētās paketes varētu iziet. Kad šis izņēmums pazūd vai saglabā nākamo lēcienu, kura vairs nav, paša tuneļa ārējās paketes atbilst puslielajam maršrutam un tiek sūtītas atpakaļ tunelī. Rezultāts ir savienojums, kas mirst nākamajā keepalive vai rokasspiedienā, un žurnālā nav nekā, kas izskatītos pēc maršrutēšanas kļūdas.

Apstipriniet tabulas formu, pirms kam citam pieskaraties. ip route show jāuzskaita abas puses plus maršruts uz resursdatoru servera adresei; kad maršruta uz resursdatoru trūkst, pārējam izmeklējumam ir acīmredzams sākumpunkts.

Kāpēc puslielie noklusējuma maršruti uzvar bez metrikas maiņas

Zemāka metrika nepārspēj garāku prefiksu. Maršruti /1 uzvar tāpēc, ka kodols vispirms saskaņo konkrētāko maršrutu, tāpēc metrikas paaugstināšana noklusējuma maršrutā neko nemaina jautājumā, kurp dodas uz tuneli vērstā plūsma. Metriku dzenāšanās ir visbiežākais nepareizais pagrieziens šajā diagnostikā.

Pārbaudiet izvēli ar ip route get 203.0.113.10, aizstājot to ar īsto servera adresi. Atbilde nosauc saskarni un nākamo lēcienu, ko kodols faktiski izmantotu, un tas ir informatīvāk nekā lasīt tabulu un prātot par to.

Izpildiet šo komandu pirms tuneļa sākuma, tam strādājot un pēc nomas notikuma. Trīs atbildes no vienas komandas, un atšķirības punkts kļūst redzams.

Uzņemiet trīs momentuzņēmumus, nevis vienu

Apkopojiet piekļuves adresi, piekļuves vārteju, galapunkta galamērķi, izvēlēto maršrutu un visus politikas noteikumus trīs brīžos: pēc piekļuves saites konfigurēšanas, pēc VPN savienojuma un pēc nomas vai operatora notikuma. Katrs momentuzņēmums ir sauja komandu, un tiem ir jēga tikai kopā. Viens momentuzņēmums pēc kļūmes fiksē stāvokli, nevis pāreju. Ierakstiet komandas mazā skriptā, lai katrs momentuzņēmums tiktu uzņemts vienādi.

Glabājiet momentuzņēmumus vienā failā ar laikatzīmēm, jo vēlāk interesantais jautājums ir secība. Vai DHCP notikums atnāca pirms tam, kad OpenVPN atjaunoja savu maršrutu, vai pēc tam? Atbilde izšķir, kam tas jālabo. Laikatzīme no nepareiza pulksteņa ir sliktāka par nekādu, tāpēc ņemiet to no resursdatora, kuram pieder maršrutēšanas tabula.

Kad galapunkts konfigurēts kā nosaukums, nevis adrese, atrisiniet to arī katrā momentuzņēmumā. DNS izmaiņas piekļuves saitē var pārvietot galapunktu, vispār neaizskarot nevienu maršrutu.

Izlemiet, kura komponente atjauno izņēmumu

dhcpcd sistēmā āķi darbojas no āķu direktorija un no izejas āķa, un pārvaldnieka režīms apjoma ziņā atšķiras no režīma katrai saskarnei. Lai ko āķis darītu, tam jābūt idempotentam, jo atjauninājumi var nākt grūzmēm.

Uzticamais īpašnieks ir integrācija, kas jau pazīst abas puses: tīkla pārvaldnieks, kas pārvalda VPN savienojumu, vai unit, kas sakārtota pēc piekļuves saites pacelšanās. Āķa pievienots statiskais maršruts darbojas līdz nākamajai vārtejas maiņai, un tad neizdodas tieši tāpat. Ja tomēr lietojat āķi, lieciet tam izpildes laikā nolasīt pašreizējo vārteju, nevis iekodēt to, ko šodien redzējāt.

Pierakstiet īpašnieku konfigurācijā. Nākamajam cilvēkam, kas atkļūdos atkārtotu savienojumu, jāzina, ka par izņēmuma maršrutu atbild āķis, nevis VPN.

Pārbaudiet dzīves ciklu, ne tikai atkārtotu savienojumu

Piespiediet atjauninājumu ar dhcpcd -n eth0 vai atlaižot un no jauna paņemot nomu, tad vēlreiz pārbaudiet ip route get galapunktam. Izdariet to divreiz, jo otrais piegājiens noķer āķus, kas pievieno dublētus maršrutus. Tad pārstartējiet, jo noturība ir cita īpašība nekā pareizība.

Tunelim, kas pārdzīvo atjauninājumu un pārstartēšanu, ir īpašnieks un strādājošs izņēmums. Tam, kas pārdzīvo tikai manuālu pārstartēšanu, nav neviena, un tas neizdosies nākamajā notikumā, kuru nevarat ieplānot.