VPN val weg ná 'n DHCP-hernuwing? Vergelyk die adresse

Huurkontrakhernuwing en VPN-foute verskyn dikwels saam in logboeke, genoeg dat mense aflei dat die een die ander veroorsaak. Die tydsberekening is werklik; die oorsaaklikheid gewoonlik nie. 'n Hernuwing is 'n unicast-versoek aan die bediener wat die huurkontrak uitgereik het, om voort te gaan met dieselfde binding, en die bediener kan dit verleng sonder dat die kliënt 'n enkele adres verander. Om die kliënt se eie waardes rondom die gebeurtenis na te gaan, skei 'n huurkontrak wat stilweg hernu is van 'n netwerk wat werklik onder 'n lopende tonnel verander het.

Begin by die kliënt wat weggeval het

Maak eerste die kliënt se verbindingslog oop en noteer die tyd van die onderbreking tot op die sekonde. Maak dan die bedryfstelsel se netwerklog vir dieselfde minuut oop en lees in volgorde wat die koppelvlak gedoen het. Dié volgorde is die hele ondersoek: 'n DHCP-gebeurtenis voor die ontkoppeling, 'n ontkoppeling voor die DHCP-gebeurtenis, en twee gebeure met niks tussenin is drie verskillende bevindings. 'n Logreël wat net die huurkontrak noem terwyl die tonnel al herverbind het, is versiering, nie bewys nie.

Skryf die tydlyn neer terwyl jy werk eerder as om dit in jou geheue te hou. Tydstempels van verskillende gereedskap pas selde perfek, en die verskil self is soms die verklaring.

Vergelyk die vier waardes rondom die gebeurtenis

Vier waardes beskryf die plaaslike kant van 'n verbinding goed genoeg om 'n werklike verandering te betrap: die koppelvlakadres, die verstekpoort, die resolver-lys en die koppelvlak se bedryfstoestand. Neem dit binne 'n minuut na die onderbreking op en vergelyk dit met 'n opname wat geneem is toe die tonnel gesond was.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Onveranderde adres met onveranderde poort en veranderde resolver-lys dui op naamoplossing eerder as roetering, en die tonnel kon oorleef het terwyl toepassings opgehou het om gashere te vind. 'n Veranderde poort beteken die pad uit die plaaslike netwerk het geskuif, wat genoeg is om 'n roete te verydel wat na die vorige een gewys het. As al vier waardes met die gesonde opname ooreenstem, is die huurkontrak nie jou oorsaak nie en word die kliënt se eie herverbindingslogika die onderwerp. Neem die vergelyking op terwyl die fout sigbaar is, want 'n gesonde opname wat ná 'n herbegin geneem is, het 'n ander adreshistorie en sal nie pas nie.

Wat 'n hernuwing kan en nie kan verander nie

RFC 2131 beskryf hernuwing as 'n versoek aan die oorspronklike bediener op die helfte van die huurtyd, met herbinding aan enige bediener op sewe agtstes as die eerste poging onbeantwoord bly. Nie een van die stappe vereis dat die kliënt 'n ander adres kry nie, en 'n samewerkende bediener verleng gewoonlik die bestaande binding. 'n Werklike adresverandering kom gewoonlik via 'n ander pad: 'n bediener wat die hernuwing weier, 'n kliënt wat sy toestand verloor het en oor begin het, of 'n netwerk wat die toestel na 'n ander segment geskuif het.

Die publieke kant van die verbinding kan verander sonder enige plaaslike verandering. Agter carrier-grade-omsetting kan die adres wat die VPN-eweknie sien, onafhanklik van enigiets wat die plaaslike huurkontrak gedoen het, hertoegewys word, en dié hertoewysing lyk van binne die kliënt identies aan 'n plaaslike netwerkfout. Om 'n plaaslik gerapporteerde adres met 'n waarneming van die eweknie te vergelyk, is die enigste manier om hulle te skei.

Wanneer die kliënt nie kan aanpas nie

'n Kliënt wat sy transport aan die ou adres gebind het, 'n verouderde roete na die eweknie gekas het of 'n koppelvlak-identiteit gestoor het, kan aanhou probeer op 'n pad wat nie meer bestaan nie. Dit is 'n aanpassingsfout, en dit is sigbaar as herhaalde herversendings na 'n adres wat die gasheer nie meer kan bereik nie. Sommige kliënte hanteer dit per ontwerp: WireGuard, byvoorbeeld, werk 'n eweknie se eindpunt by wanneer 'n korrek geauthentiseerde pakket van 'n nuwe bron aankom.

'n Handmatige herbegin wat diens herstel, is 'n leidraad oor waar die aanpassing misluk het, nie 'n bewys dat huurkontrakte en tonnels onversoenbaar is nie. Hou die blokkeringsbeleid in plek terwyl jy toets, anders word die toets self 'n onderbreking met 'n ander oorsaak. Teken op of die kliënt vanself herstel het, hoe lank dit geneem het en watter adres hy weer probeer het; dié volgorde vertel jou meer as die ontkoppelingsrede wat in die koppelvlak gewys word.

Herhaal die gebeurtenis voordat jy dit blameer

Reproduseer die toestand eerder as om vir die skedule te wag: laat die huurkontrak vry en hernu dit, of forseer die ekwivalente gekontroleerde gebeurtenis, en kyk of die tonnel oorleef. Op 'n bestuurde netwerk, koördineer enige adresverandering met die netwerkeienaar, want 'n willekeurige statiese toewysing kan bots met 'n toestel wat daardie adres al het.

Herhaal ná 'n ondersteunde oplossing dieselfde gebeurtenis en toets dan 'n toepassing en 'n naamsoektog, want 'n tonnel wat herverbind maar DNS breek, slaag 'n swakker toets as die een wat saak maak. Rapporteer die spesifieke verandering wat jy waargeneem het, met sy tydstempel, in plaas daarvan om die geskeduleerde huurkontrak as oorsaak te noem. Die verskil tussen dié twee verslae is of die volgende persoon die fout kan reproduseer of net die gerug.