Mae OpenVPN yn cwympo ar ôl adnewyddiad DHCP: cadwch lwybr y pen draw

Mae'r twnnel yn cysylltu, yna mae adnewyddiad les ar y cyswllt mynediad yn ei ladd, ac mae'r log yn beio terfyn amser yn hytrach na llwybr. Nid oes dim wedi newid yn ffurfweddiad y VPN, a dyna'r cliw: mae rhywbeth y tu allan iddo wedi newid. Mae digwyddiad DHCP wedi ailysgrifennu'r cyfeiriad neu'r porth, ac mae llwybr y gwesteiwr a oedd yn cadw pen draw'r twnnel yn gyrraeddadwy nawr yn pwyntio at naid nesaf nad yw'n bodoli mwyach. Mae hwn yn broblem perchnogaeth cyn iddo fod yn broblem llwybrau.

Cymharwch y symptom â'r llwybrau hanner-diofyn

Gyda redirect-gateway def1, mae OpenVPN yn gosod 0.0.0.0/1 a 128.0.0.0/1 yn hytrach nag amnewid y llwybr diofyn. Gyda'i gilydd mae'r ddau yn gorchuddio'r gofod cyfeiriad cyfan, ac maent yn curo 0.0.0.0/0 ar hyd y rhagddodiad yn unig. Felly mae unrhyw gyrchfan heb gydweddiad mwy penodol yn mynd i'r twnnel.

Mae angen eithriad ar y pen draw. Mae OpenVPN yn ychwanegu llwybr gwesteiwr i gyfeiriad y gweinydd drwy'r porth mynediad gwreiddiol cyn i'r hanner-diofynion fynd i mewn, fel y gall pecynnau sydd wedi'u hamgáu adael. Pan fydd yr eithriad hwnnw'n diflannu, neu'n cadw naid nesaf nad yw'n bodoli mwyach, mae pecynnau allanol y twnnel ei hun yn cyfateb i hanner-diofyn ac yn cael eu hanfon yn ôl i'r twnnel. Y canlyniad yw cysylltiad sy'n marw ar y keepalive neu'r ysgwyd llaw nesaf, heb ddim yn y log sy'n edrych fel gwall llwybrau.

Cadarnhewch siâp y tabl cyn cyffwrdd â dim arall. Dylai ip route show restru'r ddwy hanner ynghyd â llwybr gwesteiwr ar gyfer cyfeiriad y gweinydd; pan fo'r llwybr gwesteiwr ar goll, mae gan weddill yr ymchwiliad fan cychwyn amlwg.

Pam mae'r hanner-diofynion yn ennill heb newid metrig

Nid yw metrig is yn curo rhagddodiad hirach. Mae'r llwybrau /1 yn ennill oherwydd bod y cnewyllyn yn cyfateb y llwybr mwyaf penodol yn gyntaf, felly nid yw codi metrig ar y llwybr diofyn yn newid dim ynglŷn â ble mae traffig tuag at y twnnel yn mynd. Yr encil anghywir mwyaf cyffredin yn y diagnosis hwn yw hel ar ôl metrigau.

Gwiriwch y dewis gyda ip route get 203.0.113.10, gan roi cyfeiriad gwirioneddol y gweinydd yn ei le. Mae'r ateb yn enwi'r rhyngwyneb a'r naid nesaf y byddai'r cnewyllyn yn eu defnyddio mewn gwirionedd, sy'n fwy addysgiadol na darllen tabl a rhesymu amdano.

Rhedwch y gorchymyn hwnnw cyn i'r twnnel ddechrau, tra bo'n fyw, ac ar ôl digwyddiad y les. Tri ateb o un gorchymyn, ac mae'r pwynt dargyfeirio yn dod yn weladwy.

Cymerwch dri chiplun, nid un

Casglwch y cyfeiriad mynediad, y porth mynediad, cyrchfan y pen draw, y llwybr a ddewiswyd ac unrhyw reolau polisi ar dri munud: ar ôl ffurfweddu'r cyswllt mynediad, ar ôl i'r VPN gysylltu, ac ar ôl digwyddiad y les neu'r cludwr. Mae pob ciplun yn llond llaw o orchmynion, ac nid ydynt yn golygu dim ond gyda'i gilydd. Mae un ciplun ar ôl methiant yn cofnodi'r cyflwr yn hytrach na'r newid. Ysgrifennwch y gorchmynion mewn sgript fach fel bod pob ciplun yn cael ei gymryd yr un ffordd.

Cadwch y cipluniau mewn un ffeil â stampiau amser, oherwydd y cwestiwn diddorol yn ddiweddarach yw'r drefn. A ddaeth y digwyddiad DHCP cyn neu ar ôl i OpenVPN adnewyddu ei lwybr? Mae'r ateb yn penderfynu pwy sydd i'w drwsio. Mae stamp amser o gloc anghywir yn waeth nag un o gwbl, felly cymerwch ef o'r gwesteiwr sy'n berchen ar y tabl llwybrau.

Pan fo'r pen draw wedi'i ffurfweddu fel enw yn hytrach na chyfeiriad, datryswch ef ym mhob ciplun hefyd. Gall newid DNS ar y cyswllt mynediad symud y pen draw heb gyffwrdd ag unrhyw lwybr o gwbl.

Penderfynwch pa gydran sy'n adnewyddu'r eithriad

Ar system dhcpcd, mae bachau'n rhedeg o'r cyfeiriadur bachau ac o'r bachyn allanfa, ac mae modd rheolwr yn wahanol o ran cwmpas i fodd fesul rhyngwyneb. Beth bynnag y mae'r bachyn yn ei wneud, rhaid iddo fod yn idempotent, gan y gall adnewyddiadau ddod mewn pyliau.

Y perchennog dibynadwy yw'r integreiddiad sy'n adnabod y ddwy ochr yn barod: rheolwr rhwydwaith sy'n rheoli'r cysylltiad VPN, neu uned a drefnwyd ar ôl i'r cyswllt mynediad godi. Mae llwybr statig a ychwanegir gan fachyn yn gweithio tan y newid porth nesaf, ac yna'n methu yn union yr un ffordd. Os ydych chi'n defnyddio bachyn, gwnewch iddo ddarllen y porth cyfredol yn ystod rhedeg yn lle codio'n galed yr un a welsoch heddiw.

Cofnodwch y perchennog o fewn y ffurfweddiad. Bydd angen i'r person nesaf sy'n dadfygio ailgysylltiad wybod mai bachyn, nid y VPN, sy'n gyfrifol am lwybr yr eithriad.

Profwch y cylch bywyd, nid yr ailgysylltiad yn unig

Gorfodwch adnewyddiad gyda dhcpcd -n eth0 neu drwy ryddhau ac adnewyddu'r les, yna gwiriwch ip route get ar gyfer y pen draw eto. Gwnewch hynny ddwywaith, oherwydd mae'r ail rediad yn dal bachau sy'n ychwanegu llwybrau dyblyg. Yna ailgychwynnwch, oherwydd mae parhauster yn briodwedd wahanol i gywirdeb.

Mae gan dwnnel sy'n goroesi adnewyddiad ac ailgychwyn berchennog a eithriad sy'n gweithio. Nid oes gan un sy'n goroesi ailgychwyn â llaw y naill na'r llall, a bydd yn methu ar y digwyddiad nesaf na allwch ei drefnu.