OpenVPN bie pas një rinovimi DHCP: mbaj rrugën e pikës fundore

Tuneli lidhet, pastaj një rinovim i qirasë në lidhjen e aksesit e vret, dhe regjistri fajëson një afat kohor në vend të një rruge. Asgjë në konfigurimin e VPN nuk ka ndryshuar, dhe ky është indici: diçka jashtë tij ka ndryshuar. Një ngjarje DHCP rishkruajti adresën ose portën, dhe rruga e hostit që e mbante pikën fundore të tunelit të arritshme tani tregon një hop tjetër që nuk ekziston më. Ky është një problem pronësie përpara se të jetë problem rrugëtimi.

Krahaso simptomën me rrugët gjysmë-parazgjedhura

Me redirect-gateway def1, OpenVPN instalon 0.0.0.0/1 dhe 128.0.0.0/1 në vend që të zëvendësojë rrugën parazgjedhur. Së bashku, të dyja mbulojnë të gjithë hapësirën e adresave, dhe mundin 0.0.0.0/0 vetëm me gjatësinë e prefiksit. Prandaj çdo destinacion pa një përputhje më specifike hyn në tunel.

Pika fundore ka nevojë për një përjashtim. OpenVPN shton një rrugë hosti drejt adresës së serverit përmes portës origjinale të aksesit përpara se gjysmë-parazgjedhurat të hyjnë, që paketat e inkapsuluara të mund të dalin. Kur ai përjashtim zhduket, ose mban një hop tjetër që nuk ekziston më, paketat e jashtme të vetë tunelit përputhen me një gjysmë-parazgjedhur dhe dërgohen përsëri brenda tunelit. Rezultati është një lidhje që vdes në keepalive ose shtrëngimin e dorës tjetër, pa asgjë në regjistër që të duket si gabim rrugëtimi.

Konfirmo formën e tabelës përpara se të prekësh çdo gjë tjetër. ip route show duhet të listojë të dyja gjysmat plus një rrugë hosti për adresën e serverit; kur mungon rruga e hostit, pjesa tjetër e hetimit ka një pikënisje të dukshme.

Pse gjysmë-parazgjedhurat fitojnë pa ndryshuar metrikën

Një metrikë më e ulët nuk mund një prefiks më të gjatë. Rrugët /1 fitojnë sepse bërthama përputh rrugën më specifike së pari, kështu që ngritja e një metrike në rrugën parazgjedhur nuk ndryshon asgjë rreth asaj se ku shkon trafiku i drejtuar drejt tunelit. Ndjekja e metrikave është kthesa e gabuar më e zakonshme në këtë diagnozë.

Kontrollo zgjedhjen me ip route get 203.0.113.10, duke zëvendësuar adresën e vërtetë të serverit. Përgjigja emërton ndërfaqen dhe hopin tjetër që bërthama do të përdorte vërtet, çka është më informuese sesa të lexosh një tabelë dhe të arsyetosh mbi të.

Ekzekuto atë komandë përpara se tuneli të nisë, ndërsa është aktiv dhe pas ngjarjes së qirasë. Tre përgjigje nga një komandë, dhe pika e divergjencës bëhet e dukshme.

Merr tre pamje, jo një

Mblidh adresën e aksesit, portën e aksesit, destinacionin e pikës fundore, rrugën e zgjedhur dhe çdo rregull politike në tre momente: pasi lidhja e aksesit konfigurohet, pasi VPN lidhet dhe pas ngjarjes së qirasë ose të operatorit. Çdo pamje është një grusht komandash, dhe kanë kuptim vetëm së bashku. Një pamje e vetme pas dështimit regjistron gjendjen, jo kalimin. Shkruaj komandat në një skript të vogël që çdo pamje të merret në të njëjtën mënyrë.

Mbaji pamjet në një skedar të vetëm me vulat kohore, sepse pyetja interesante më vonë është renditja. A erdhi ngjarja DHCP përpara apo pasi OpenVPN rifreskoi rrugën e tij? Përgjigja vendos kush duhet ta rregullojë. Një vulë kohore nga një orë e gabuar është më e keqe se asnjë, prandaj merre nga hosti që zotëron tabelën e rrugëtimit.

Kur pika fundore konfigurohet si emër dhe jo si adresë, zgjidhe edhe në çdo pamje. Një ndryshim DNS në lidhjen e aksesit mund ta zhvendosë pikën fundore pa u prekur asnjë rrugë.

Vendos cila komponent e rifreskon përjashtimin

Në një sistem dhcpcd, grepët ekzekutohen nga drejtoria e grepëve dhe nga grepi i daljes, dhe modaliteti menaxher ndryshon në shtrirje nga modaliteti për ndërfaqe. Çfarëdo që bën grepi, duhet të jetë idempotent, sepse rinovimet mund të vijnë me valë.

Zotëruesi i besueshëm është integrimi që tashmë i njeh të dyja anët: një menaxher rrjeti që administron lidhjen VPN, ose një njësi e renditur pasi lidhja e aksesit ngrihet. Një rrugë statike e shtuar nga një grep funksionon deri në ndryshimin tjetër të portës, pastaj dështon në të njëjtën mënyrë. Nëse prapë përdor një grep, bëje atë të lexojë portën aktuale në kohën e ekzekutimit në vend që të kodojë fort atë që pe sot.

Regjistro zotëruesin brenda konfigurimit. Personi tjetër që do të korrigjojë një rilidhje duhet të dijë se është një grep, jo VPN, ai që përgjigjet për rrugën e përjashtimit.

Testo ciklin e jetës, jo vetëm rilidhjen

Detyro një rinovim me dhcpcd -n eth0 ose duke lëshuar dhe rinovuar qiranë, pastaj kontrollo përsëri ip route get për pikën fundore. Bëje dy herë, sepse kalimi i dytë kap grepët që shtojnë rrugë të dyfishuara. Pastaj rinis, sepse këmbëngulja është një veti tjetër nga korrektësia.

Një tunel që i mbijeton një rinovimi dhe një rinisjeje ka zotërues dhe një përjashtim që funksionon. Ai që i mbijeton vetëm një rinisjeje manuale nuk ka as njërën as tjetrën, dhe do të dështojë në ngjarjen tjetër që nuk mund ta planifikosh.