Rekursiewe roetering: wanneer die tonnel sy eie pakkette vasvang

Die tonnel kom op, die log wys ’n voltooide handdruk, en ’n sekonde later sterf dieselfde sessie en herverbind in ’n lus. Daardie patroon het ’n spesifieke oorsaak: die roete na die bediener wys nou in die tonnel in, so die pakkette wat die tonnel dra, word deur die tonnel gestuur. Niks aan die verifikasie het verander nie, en daarom maak dit geen verskil om die geloofsbriewe weer in te voer nie. Vergelyk die buitenste pad voor en ná die roeteverandering, dan word die rekursie sigbaar.

Kyk eers na die buitenste pad

Daar is twee pakkette in die spel, nie een nie. Die binneste pakket behoort aan die toepassing en behoort geïnkripteer te wees, terwyl die buitenste pakket aan die bediener geadresseer is en dit oor ’n pad moet bereik wat nie van die tonnel afhang nie.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Vra die kern vir die roete na die bediener se adres nadat die tonnel op is, en weer nadat die verstekroete verander het. ’n Volgende sprong wat op die tonneltoestel beland, is juis die rekursie, en dit is sigbaar sonder enige pakketopname. Koppelvlakbinding, merke of ’n netwerknaamruimte kan ’n gewone opsoek onvolledig maak, so gebruik die konteks wat die kliënt self gebruik. Wanneer die antwoord korrek lyk maar die sessie steeds lus, lees die roeteringsbeleidreëls eerder as net die hooftabel.

Waarom die sessie ’n oomblik hou

Die handdruk voltooi voordat die nuwe roete geïnstalleer word, so die eerste sekondes lyk gesond. Sodra die kliënt die verstekroete byvoeg, volg die volgende buitenste pakket dit in die koppelvlak in wat daardie buitenste pakket nodig het om te reis. Die bediener sien niks, die kliënt stuur weer, en die herpoging loop óf op ’n tydverstreke wag óf maak die sessie dood en begin oor.

Daardie volgorde verduidelik waarom ’n tonnel op ’n skootrekenaar kan werk en op ’n roeteerder kan misluk, en waarom die fout dikwels begin wanneer verkeer begin eerder as by die verbinding. Dit verduidelik ook die lus: elke herbegin herstel die sessie voordat die roete dit onmoontlik maak.

Soek wie die eindpunt-uitsondering besit

Ondersteunde kliënte reël hulle eie uitsondering: ’n gasheerroete na die bediener deur die oorspronklike poort, of ’n merk wat die buitenste sokkie uit die tonnel hou. Die vraag is of iets anders dit verwyder of oorheers het.

Vir roetegebaseerde IPsec moet jy die beleidskeurders ondersoek wat besluit watter pakkette die tonnel binnegaan, en bevestig dat die eweknie-adres daaruit uitgesluit is. Vir WireGuard hou die koppelvlak se brandmuurmerk en sy beleidsreëls die vervoerpakkette buite die tonnel, so ’n handmatig bygevoegde verstekroete kan daardie reëling breek. ’n Tweede VPN-profiel of ’n bestuurscript wat die verstekroete herskryf, is ’n algemene skuldige. Breë omleidingsreëls wat een vir een bygevoeg word, is die gewone gevolg, en hulle verander ’n roeteringsfout in ’n tabel wat niemand kan onderhou nie.

Kontroleer weer ná ’n netwerkverandering

’n Gasheerroete deur ’n Wi-Fi-poort is korrek totdat die masjien na ’n ander netwerk skuif. Dieselfde simptoom keer dan terug sonder enige verandering aan die konfigurasie.

Teken die eindpuntadres aan, die roete voor en ná verbinding, en die koppelvlak wat elkeen gebruik het. Daardie drie feite skei gewoonlik ’n kliëntfout van ’n oorheersing, en hulle oorleef die persoon wat hulle ingesamel het.

Verbind weer op die nuwe netwerk en herhaal die lees. As die uitsondering weer ontbreek, hoort die regstelling in die profiel wat dit besit, nie in ’n eenmalige opdrag wat tydens ’n onderbreking getik is nie.