OpenVPN val weg ná ’n DHCP-hernuwing: hou die eindpunt-roete

Die tonnel maak verbinding, dan maak ’n huurhernuwing op die toegangskakel dit dood, en die log gee ’n tydsverloop die skuld eerder as ’n roete. Niks in die VPN-konfigurasie het verander nie, en dit is die leidraad: iets daarbuite het. ’n DHCP-gebeurtenis het die adres of die poort herskryf, en die gasheerroete wat die tonnel-eindpunt bereikbaar gehou het, wys nou na ’n volgende sprong wat nie meer bestaan nie. Dit is ’n eienaarskapprobleem voordat dit ’n roeteprobleem is.

Kontroleer die simptoom teen die halfverstek-roetes

Met redirect-gateway def1 installeer OpenVPN 0.0.0.0/1 en 128.0.0.0/1 eerder as om die verstekroete te vervang. Saam dek dié twee die hele adresruimte, en hulle klop 0.0.0.0/0 bloot op voorvoegsellengte. Enige bestemming sonder ’n meer spesifieke passing gaan dus in die tonnel in.

Die eindpunt het ’n uitsondering nodig. OpenVPN voeg ’n gasheerroete na die bedieneradres deur die oorspronklike toegangspoort by voordat die halfverstekke ingaan, sodat ingekapselde pakkette kan uitgaan. Wanneer daardie uitsondering verdwyn, of ’n volgende sprong hou wat nie meer bestaan nie, pas die tonnel se eie buitenste pakkette by ’n halfverstek en word hulle terug die tonnel in gestuur. Die gevolg is ’n verbinding wat by die volgende lewendighouding of handdruk doodgaan, met niks in die log wat soos ’n roetefout lyk nie.

Bevestig die vorm van die tabel voordat jy aan enigiets anders raak. ip route show behoort albei helftes plus ’n gasheerroete vir die bedieneradres te lys; wanneer die gasheerroete ontbreek, het die res van die ondersoek ’n duidelike beginpunt.

Waarom die halfverstekke sonder ’n metrieke verandering wen

’n Laer metrieke waarde klop nie ’n langer voorvoegsel nie. Die /1-roetes wen omdat die kern eerste die mees spesifieke roete pas, so om ’n metrieke waarde op die verstekroete te verhoog verander niks aan waar tonnelbestemde verkeer heen gaan nie. Om metrieke na te jaag is die mees algemene verkeerde draai in hierdie diagnose.

Kontroleer die keuse met ip route get 203.0.113.10, en vervang dit met die werklike bedieneradres. Die antwoord noem die koppelvlak en volgende sprong wat die kern werklik sou gebruik, wat meer insiggewend is as om ’n tabel te lees en daaroor te redeneer.

Voer daardie opdrag uit voordat die tonnel begin, terwyl dit op is, en ná die huurgebeurtenis. Drie antwoorde uit een opdrag, en die punt van afwyking word sigbaar.

Neem drie momentopnames, nie een nie

Versamel die toegangsadres, die toegangspoort, die eindpuntbestemming, die gekose roete en enige beleidsreëls op drie oomblikke: nadat die toegangskakel opgestel is, nadat die VPN verbind het, en ná die huur- of draergebeurtenis. Elke momentopname is ’n handvol opdragte, en hulle beteken net iets saam. ’n Enkele momentopname ná die fout teken die toestand op eerder as die oorgang. Skryf die opdragte in ’n klein script sodat elke momentopname op dieselfde manier geneem word.

Hou die momentopnames in een lêer met tydstempels, want die interessante vraag later is die volgorde. Het die DHCP-gebeurtenis gekom voor of nadat OpenVPN sy roete verfris het? Die antwoord besluit wie dit moet regmaak. ’n Tydstempel van die verkeerde klok is erger as geen, so neem dit van die gasheer wat die roetetabel besit.

Wanneer die eindpunt as ’n naam eerder as ’n adres opgestel is, los dit ook in elke momentopname op. ’n DNS-verandering op die toegangskakel kan die eindpunt verskuif sonder dat enige roete aangeraak word.

Besluit watter komponent die uitsondering verfris

Op ’n dhcpcd-stelsel loop hake uit die haakgids en uit die uithaak, en bestuurdersmodus verskil in omvang van per-koppelvlakmodus. Wat die haak ook doen, dit moet idempotent wees, want hernuwings kan in sarsies aankom.

Die betroubare eienaar is die integrasie wat albei kante al ken: ’n netwerkbestuurder wat die VPN-verbinding bestuur, of ’n eenheid wat bestel is nadat die toegangskakel opkom. ’n Statiese roete wat deur ’n haak bygevoeg word, werk tot die volgende poortverandering en faal dan op presies dieselfde manier. As jy wel ’n haak gebruik, laat dit die huidige poort tydens uitvoering lees eerder as om die een wat jy vandag gesien het, hard te kodeer.

Teken die eienaar in die konfigurasie op. Die volgende persoon wat ’n herverbinding ontfout, moet weet dat ’n haak, nie die VPN nie, verantwoordelik is vir die uitsonderingroete.

Toets die lewensiklus, nie net die herverbinding nie

Forseer ’n hernuwing met dhcpcd -n eth0 of deur die huur vry te laat en te hernu, en kyk dan weer met ip route get na die eindpunt. Doen dit twee keer, want die tweede lopie vang hake wat duplikaatroetes byvoeg. Herbegin dan, want volharding is ’n ander eienskap as korrektheid.

’n Tonnel wat ’n hernuwing en ’n herbegin oorleef, het ’n eienaar en ’n werkende uitsondering. Een wat net ’n handmatige herbegin oorleef, het nie een van die twee nie, en sal faal by die volgende gebeurtenis wat jy nie kan skeduleer nie.