OpenVPN falt nei in DHCP-ferrinijing: hâld de rûte nei it einpunt

De tunnel ferbynt, dan deadet in ferhierferrinijing op ’e tagongskeppeling it, en it loch jout in tiidlimit de skuld yn stee fan in rûte. Der is neat feroare yn ’e VPN-konfiguraasje, en dat is de oanwizing: eat bûten dy is feroare. In DHCP-evenemint hat it adres of de poarte oerskreaun, en de hostrûte dy’t it einpunt fan ’e tunnel berikber hâlde, wiist no nei in folgjende hop dy’t net mear bestiet. Dit is in eigendomsprobleem foardat it in routingprobleem is.

Fergelykje it symptoom mei de healsstandertrûtes

Mei redirect-gateway def1 ynstallearret OpenVPN 0.0.0.0/1 en 128.0.0.0/1 yn stee fan ’e standertrûte te ferfangen. Tegearre dekke dy twa de hiele adresromte, en se ferslaan 0.0.0.0/0 allinnich al op ’e lingte fan it foarheaksel. Dêrom giet elk bestimming sûnder in spesifiker oerienkomst de tunnel yn.

It einpunt hat in útsûndering nedich. OpenVPN foeget in hostrûte ta oan it adres fan ’e server fia de oarspronklike tagongspoarte foardat de healsstanderts yngean, sadat ynkapsulearre pakketten fuort kinne. Wannear’t dy útsûndering ferdwynt, of in folgjende hop hâldt dy’t net mear bestiet, dan komme de eigen bûtenste pakketten fan ’e tunnel oerien mei in healsstandert en wurde se werom de tunnel yn stjoerd. It resultaat is in ferbining dy’t stjert by de folgjende keepalive of hânskodding, sûnder eat yn it loch dat op in routingflater liket.

Befêstigje de foarm fan ’e tabel foardat jo eat oars oanreitsje. ip route show heart beide helten plus in hostrûte foar it adres fan ’e server te listigjen; as de hostrûte ûntbrekt, hat de rest fan it ûndersyk in fanselssprekkend begjinpunt.

Wêrom’t de healsstanderts winne sûnder in metykferoaring

In legere metyk ferslacht gjin langer foarheaksel. De rûtes /1 winne om’t de kearn earst de meast spesifike rûte oerienkomme lit, dat in metyk op ’e standertrûte ferheegje feroaret neat oan wêr’t ferkear nei de tunnel giet. Metyk efternei jeien is de meast foarkommende ferkearde draai yn dizze diagnoaze.

Kontrolearje de seleksje mei ip route get 203.0.113.10, en ferfang it troch it echte adres fan ’e server. It antwurd neamt de ynterface en folgjende hop dy’t de kearn eins brûke soe, en dat is mear ynformtyf as in tabel lêze en deroer tinke.

Fier dat kommando út foardat de tunnel begjint, wylst dy oan is, en nei it ferhierevenemint. Trije antwurden út ien kommando, en it punt fan ôfwiking wurdt sichtber.

Nim trije momintfoto’s, net ien

Sammele it tagongsadres, de tagongspoarte, de bestimming fan it einpunt, de keazen rûte en alle beliedsregels op trije mominten: nei’t de tagongskeppeling konfigurearre is, nei’t de VPN ferbynt, en nei it ferhier- of dragerevenemint. Elke momintfoto is in hânfol kommando’s, en se betsjutte allinnich tegearre eat. In inkele momintfoto nei de flater registrearret de steat, net de oergong. Skriuw de kommando’s yn in lyts skript, sadat elke momintfoto op deselde manier nommen wurdt.

Hâld de momintfoto’s yn ien bestân mei tiidstimpels, want de nijsgjirrige fraach is letter de oarder. Kaam it DHCP-evenemint foardat of nei’t OpenVPN syn rûte ferfriste? It antwurd beslút wa’t it reparearje moat. In tiidstimpel fan ’e ferkearde klok is slimmer as gjin, dus nim it fan ’e host dy’t de routingtabel hat.

Wannear’t it einpunt as namme ynstee fan adres konfigurearre is, los it dan ek op yn elke momintfoto. In DNS-feroaring op ’e tagongskeppeling kin it einpunt ferplakke sûnder dat der ea in rûte oanreitsje.

Beslút hokker komponint de útsûndering ferfristet

Op in dhcpcd-systeem rinne hooks út ’e hookmap en út ’e útgongshook, en de beheardermodus ferskilt yn omfang fan ’e modus per ynterface. Wat de hook ek docht, it moat idempotint wêze, want ferfrissingen kinne yn skokken komme.

De betroubere eigener is de yntegraasje dy’t beide kanten al ken: in netwurkbehearder dy’t de VPN-ferbining beheart, of in unit dy’t oardere is nei’t de tagongskeppeling omheech komt. In statyske rûte dy’t troch in hook tafoege wurdt, wurket oant de folgjende poartefoararing en mislearret dan op krekt deselde manier. As jo dochs in hook brûke, lit it dan by útfiering de hjoeddeiske poarte lêze yn stee fan dy fan hjoed hurd te kodearjen.

Skriuw de eigener yn ’e konfiguraasje. De folgjende persoan dy’t in werferbining debugt, moat witte dat in hook, net de VPN, ferantwurdlik is foar de útsûnderingsrûte.

Test it libbenssyklus, net allinnich de werferbining

Twang in ferfrissing mei dhcpcd -n eth0 of troch it ferhier frij te litten en opnij te nimmen, en kontrolearje dan wer ip route get foar it einpunt. Doch it twa kear, want de twadde run fynt hooks dy’t dûbele rûtes tafoege. Start dan opnij, want persistentens is in oare eigenskip as korrektens.

In tunnel dy’t in ferfrissing en in nije start oerlibbet, hat in eigener en in wurkjende útsûndering. Ien dy’t allinnich in hânmjittige werstart oerlibbet, hat gjin fan beide, en sil mislearje by it folgjende evenemint dat jo net plenne kinne.