Roeteringstabel teenoor werklike opsoek: waar VPN-verkeer heen gaan

'n Roeteringstabelstorting is die minste nuttige diagnostiek in VPN-probleemoplossing en die een wat die meeste geplak word. Veertig reëls met prefikse vertel jou wat die masjien kón doen, nie wat dit vir die mislukte versoek gedoen het nie. Die meganisme wat jy eintlik wil hê, is die opsoek: gegewe hierdie bron en hierdie bestemming, watter reël het gepas, watter tabel is geraadpleeg, en watter koppelvlak en volgende sprong het uitgekom. Begin by een bestemming en een bron, lees dan die tabel met daardie vraag in die hand, en dieselfde uitset word bewyse in plaas van geraas.

'n Tabel is 'n stel kandidate, nie 'n besluit nie

Elke inskrywing beskryf 'n prefiks en wat om te doen met verkeer wat daarby pas: stuur dit na 'n koppelvlak, gee dit aan 'n volgende sprong, of laat val dit. Niks in daardie lys is volgens bedoeling gerangskik nie, en die inskrywing wat vir 'n mens die spesifiekste lyk, is nie altyd die een wat die kernel kies nie, want die keuse volg die langste-prefiksooreenkoms en, by gelyke prefikse, die metriek.

Dus is die eerste stap om die kernel te vra eerder as om die lys te lees. Die opsoekopdrag antwoord vir 'n bestemming, en met 'n bronargument antwoord dit vir die presiese paar wat 'n deurgestuurde of gebonde verbinding sou gebruik:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Elke adres hierbo is 'n dokumentasievoorbeeld. Die punt is die vorm van die antwoord: koppelvlak, gekose bronadres, poort, en die tabel waaruit die inskrywing kom. As daardie uitset nie ooreenstem met die koppelvlak wat jy verwag het nie, het jy die probleem met een opdrag gelokaliseer, en geen hoeveelheid lees van die volle tabel sou jou vertel het watter kandidaat gewen het nie.

Die opsoek loop eers deur reëls, dan deur tabelle

Op Linux is die besluit twee fases. Beleidsreëls word in prioriteitsorde geëvalueer, en die eerste reël wat pas, noem 'n tabel om te raadpleeg; daardie tabel doen dan die langste-prefiksooreenkoms. 'n Reël kan op bron, bestemming, firewallmerk, koppelvlak of 'n kombinasie pas, en daarom kan 'n storting van die hooftabel heeltemal akkuraat en heeltemal irrelevant wees vir die pakkie wat jy ondersoek.

ip rule show
ip route show table all | head -40
ip route show table 100

As 'n reël verkeer van jou VPN-poel na tabel 100 stuur, dan is tabel 100 die een wat saak maak, en die hooftabel is 'n lokmiddel. Dit is ook die meganisme agter brongebaseerde roetering op 'n roeteerder: dieselfde bestemming kan twee verskillende antwoorde hê, afhangend van waar die pakkie vandaan kom, en net die opsoek met 'n bronargument openbaar watter een geld.

IPv6 het sy eie reëls en tabelle. 'n Ontwerp wat beide families gebruik, het albei opsoeke nodig, en 'n werkende IPv4-antwoord sê niks oor die v6-pad wat 'n tweestapel-kliënt mag verkies nie.

Wat die VPN-kliënt installeer

Kliënte vervang gewoonlik nie die verstekroete nie, want dit sal die tonnel se eie buitenste pad breek. Hulle installeer iets spesifiekers wat op prefikslengte wen: 'n paar half-verstekke wat 0.0.0.0/1 en 128.0.0.0/1 dek, is die klassieke truuk, want albei is langer prefikse as 0.0.0.0/0 en saam dek hulle die hele ruimte. Ander installeer spesifieke private prefikse plus 'n beleidsreël, en sommige voeg 'n merk by sodat net geselekteerde verkeer gevang word.

Daarom is "die VPN het nie my verstekroete verander nie" nie bewys van 'n fout nie. Kyk wat dit wél bygevoeg het, en kyk of die betrokke bestemming binne daardie prefikse val:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Twee halfroetes is maklik om in 'n storting mis te kyk, want hulle lyk nie soos 'n verstek nie. 'n Split-tonnel-konfigurasie wat vergeet het om 'n prefiks in te sluit, lewer presies die simptoom wat jy jaag: die toepassing wat die tonnel behoort te gebruik, los en verbind eerder plaaslik. Vergelyk die geïnstalleerde prefikse met die bestemmings wat die gebruiker werklik nodig het, nie met die adresse wat jy toevallig getoets het nie. 'n Split-tonnel-lys wat die lêerbediener dek maar nie sy oplosser nie, lewer 'n verbinding wat na 'n openbare adres oplos en dan nie kan verifieer nie, wat soos 'n wagwoordprobleem lyk maar 'n roeteprobleem is.

Die buitenste roete moet ook oorleef

Die tonnel is self verkeer. Die pakkies wat die ingekapselde loonvrag dra, gaan oor die fisiese koppelvlak na die eweknie se adres, en daardie pad mag nie terug in die tonnel geroteer word nie. Wanneer dit gebeur, kry jy die kenmerkende faling waar die tonnel tot stand kom en dan ophou om verkeer deur te laat, want die vervoer vir die tonnel is nou binne die tonnel.

Kontroleer die eweknie-adres net soos jy die binneste bestemming gekontroleer het, en bevestig dat dit na die fisiese koppelvlak oplos eerder as na die tonnel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

'n Rekursiewe roete, 'n beleidsreël wat die eweknie vang, of 'n verstek wat deur 'n volledige-tonnel-kliënt vervang is, is die drie gewone oorsake. Al drie is in die buitenste opsoek sigbaar, en nie een daarvan is sigbaar in 'n storting van die hooftabel wat agterna geneem is nie.

Wat roeteringsuitset jou nie kan sê nie

'n Korrekte opsoek beteken die kernel sou die pakkie êrens sinvol heen stuur. Dit beteken nie dat die vuurmuur dit toelaat, die IPsec-beleid dit dek, die NAT-reël dit vertaal, of die verre kant 'n terugroete het nie. Elkeen daarvan is 'n latere fase, en die strongSwan-notas oor aansturing beskryf die ketting wat 'n pakkie aan beide kante moet deurloop.

Dit verreken ook nie toepassingsvlak-binding nie. 'n Proses kan aan 'n koppelvlak bind, 'n merk stel, of sy eie oplosser gebruik en verbind deur 'n naam wat anders oplos as wat jy getoets het. Wanneer die opsoek reg is en die verbinding steeds misluk, is die volgende vraag watter proses dit maak en of daardie proses dieselfde tabel sien as jy.

Hou dus die diagnose georden: noem die bestemming en bron, hardloop die opsoek, lees net die tabel en reël wat die opsoek genoem het, en toets dan die volgende fase. Daardie volgorde hou 'n roeteringondersoek by minute en laat 'n rekord agter wat iemand anders kan volg, wat 'n geplakte tabel nooit doen nie.