VPN-roetemetriek verander ná verbinding: wat dit beteken
'n Laer metrieke waarde breek net gelykop tussen ewe spesifieke roetes. Lees die beleidsreël, die voorvoegsel en die eindpunt-gasheerroete voordat jy enige VPN-roetenommer wysig.
Jy koppel die VPN, voer 'n route print uit, en die verstekroete dra nou 'n veel laer metrieke waarde as voorheen. Die natuurlike gevolgtrekking is dat die VPN die verstekroete oorgeneem het omdat sy nommer kleiner is. Soms is dit presies wat gebeur het. Dikwels is die metrieke waarde glad nie die beslissende faktor nie, en om dit te wysig verander niks, want die keuse is vroeër gemaak, deur voorvoegsellengte of deur 'n beleidsreël.
Die simptoom is werklik: verkeer wat vroeër deur die Wi-Fi-adapter gegaan het, gaan nou deur die tonnel, of andersom. Die metrieke waarde is een insette vir 'n opsoek wat in 'n vaste orde plaasvind, en dit is daardie orde wat jy moet lees voordat jy aan 'n nommer raak.
Waarmee die nommer eintlik meeding
Die eerste vergelyking is spesifisiteit, nie voorkeur nie. 'n Roete vir 10.20.0.0/16 klop 10.0.0.0/8, en albei klop 0.0.0.0/0, ongeag wat hul metrieke waarde sê. 'n VPN wat 'n verstekroete met die laagste metrieke waarde op die masjien installeer, verloor steeds teen enige meer spesifieke roete wat by die bestemming pas, insluitend die gasheerroete wat die kliënt vir sy eie bediener installeer.
Dit is waarom die verlaging van die metrieke waarde op 'n verstek nie 'n direk gekoppelde subnet in die tonnel kan forseer nie. As jy daardie subnet binne die VPN wil hê, voeg 'n roete vir die voorvoegsel by of kies die tonneltabel met 'n beleidsreël. Die metrieke waarde is die verkeerde hefboom vir daardie werk.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux besluit oor die tabel voor die metrieke waarde
Op Linux raadpleeg die kernel eerste die beleidsdatabasis. ip rule lys die reëls en die tabelle wat hulle kies, en ip route get 203.0.113.10 rapporteer die tabel, roete en bronadres wat die kernel werklik vir daardie bestemming sou gebruik. 'n Metrieke waarde binne tabel 100 meeding nooit met 'n roete in die hooftabel nie, want die reël het die tabel gekies voordat enige metrieke waarde vergelyk is.
Dit is waarom 'n roete in ip route show table all reg kan lyk en steeds nie verkeer dra nie. Lees die reël wat gepas het, lees dan die tabel wat dit gekies het, en vergelyk dan roetes binne daardie tabel. As die verkeerde tabel gekies is, sal geen metrieke wysiging in die ander tabel help nie.
Windows kombineer twee metrieke waardes
Windows het nie by verstek 'n beleidsdatabasis nie, maar dit kombineer wel 'n roetemetriek met 'n koppelvlakmetriek, en die outomatiese koppelvlakmetriek kan verander met skakelspoed en adaptertoestand. Dit is waarom dieselfde roete anders kan optree nadat 'n dokstasie of 'n virtuele adapter verskyn. Find-NetRoute -RemoteIPAddress 203.0.113.10 rapporteer die gekose bronadres, volgende sprong en koppelvlak, wat nader aan die werklike besluit is as die rou tabel.
Lees die roete- en koppelvlakwaardes saam. Om 'n koppelvlakmetriek te verhoog kan verkeer verskuif sonder dat enige roete-inskrywing verander, en 'n VPN-kliënt wat sy roetes besit, sal hulle by herverbinding herinstalleer en jou wysiging verwerp.
Hou die tonnel-eindpunt buite die tonnel
Elke tonnel het 'n pad na sy eie bediener nodig wat nie deur die tonnel loop nie. Kliënte installeer 'n gasheerroete vir die eindpunt deur die fisiese gateway, en daardie roete moet meer spesifiek bly as die verstek wat die kliënt byvoeg. Vee dit uit, of maak dat die tonnel die opsoek vir daardie adres wen, en die ingekapselde pakkette probeer die tonnel binnegaan wat hulle veronderstel is om te bou. Die verbinding misluk of loop in 'n kring.
Kontroleer daardie gasheerroete voor en ná enige metrieke wysiging: dit moet na die fisiese volgende sprong wys en 'n herverbinding oorleef. As die kliënt dit besit, verander die profiel of die bestuurde konfigurasie eerder as 'n looptydwaarde wat oorgeskryf sal word.
Kontroleer beide adresfamilies en die app-konteks
IPv4 en IPv6 is aparte besluite met aparte tabelle. 'n VPN kan IPv4 dra terwyl IPv6 aanhou om die plaaslike router te gebruik, en 'n metrieke verandering in een familie sê niks oor die ander nie. Kontroleer albei, en kontroleer dan die toepassingskonteks. 'n Proses wat aan 'n koppelvlak gebind is, 'n houer-naamruimte of 'n VPN per app kan 'n ander tabel sien as jou shell.
Verifieer met die instrument wat die besluit vir die werklike bestemming rapporteer, nie die volledige tabellys nie. As die gekose roete die een is wat die ontwerp bedoel, stop. 'n Metriek wat nie die kleinste nommer op die skerm is nie, is nie 'n fout nie, en om dit die kleinste te dwing, kan die eindpuntpad breek waarvan die tonnel afhanklik is.