In routingtabeldump is de minst nuttige diagnostyk by it oplossen fan VPN-problemen en de ien dy't it meast plakt wurdt. Fjirtich rigels mei prefiksen fertelle dy wat de masine dwaan koe, net wat er die foar it mislearre fersyk. It meganisme datst eins wolst, is de syktocht: jûn dizze boarne en dizze bestimming, hokker regel paste, hokker tabel waard rieplachte, en hokker ynterface en folgjende hop kamen der út. Begjin by ien bestimming en ien boarne, lês dan de tabel mei dy fraach yn 'e hân, en deselde útfier wurdt bewiis ynstee fan lûd.

In tabel is in set kandidaten, gjin beslút

Elke yngong beskriuwt in prefiks en wat te dwaan mei ferkear dat dêrby past: stjoer it nei in ynterface, jow it oan in folgjende hop, of smyt it fuort. Neat yn dy list is op bedoeling oardere, en de yngong dy't foar in minske it meast spesifyk liket, is net altyd dejinge dy't de kernel kiest, om't de kar de langste-prefiksoerienkomst folget en, by gelikense prefiksen, de metryske wearde.

Dus de earste stap is om de kernel te freegjen ynstee fan de list te lêzen. It sykkommando antwurdet foar in bestimming, en mei in boarne-argumint antwurdet it foar it krekte pear dat in trochstjoerde of bûn ferbining brûke soe:

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

Elk adres hjirboppe is in dokumintaasjefoarbyld. It giet om 'e foarm fan it antwurd: ynterface, keazen boarneaadres, gateway en de tabel dêr't de yngong wei kaam. As dy útfier net oerienkomt mei de ynterface dy'tst ferwachte, hast it probleem mei ien kommando lokaal makke, en gjin inkel lêzen fan 'e folsleine tabel hie dy ferteld hokker kandidaat wûn.

De syktocht giet earst troch regels, dan troch tabellen

Op Linux is it beslút yn twa fazen. Beliedsregels wurde yn prioriteitsfolchoarder beoardiele, en de earste regel dy't past neamt in tabel om rieplachte te wurden; dy tabel docht dan de langste-prefiksoerienkomst. In regel kin passe op boarne, bestimming, firewallmark, ynterface of in kombinaasje, en dêrom kin in dump fan 'e haadtabel folslein akkuraat en folslein irrelevant wêze foar it pakket datst ûndersykest.

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

As in regel ferkear fan dyn VPN-pool nei tabel 100 stjoert, dan is tabel 100 dejinge dy't der ta docht, en de haadtabel is in lokies. Dit is ek it meganisme efter boarnebassearre routing op in router: deselde bestimming kin twa ferskillende antwurden hawwe ôfhinklik fan wêr't it pakket wei kaam, en allinnich de syktocht mei in boarne-argumint lit sjen hokker jildt.

IPv6 hat syn eigen regels en tabellen. In ûntwerp dat beide famyljes draait hat beide syktochten nedich, en in wurkjend IPv4-antwurd seit neat oer it v6-paad dat in dual-stack-klant ferkieze kin.

Wat de VPN-klant ynstallearret

Klanten ferfange normaalwei net de standertrûte, om't dat it eigen bûtenpaad fan 'e tunnel brekke soe. Se ynstallearje eat spesifyker dat wint op prefikslengte: in pear heale standertrûtes dy't 0.0.0.0/1 en 128.0.0.0/1 dekke is de klassike trúk, want beide binne langer prefiksen as 0.0.0.0/0 en tegearre dekke se de hiele romte. Oaren ynstallearje spesifike privee prefiksen plus in beliedsregel, en guon foegje in mark ta sadat allinnich selektearre ferkear fongen wurdt.

Dêrom is "de VPN feroare myn standertrûte net" gjin bewiis fan in flater. Kontrolearje wat it dochs tafoege hat, en oft de oanbelangjende bestimming binnen dy prefiksen falt:

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

Twa heale rûtes wurde maklik mist yn in dump om't se net op in standert lykje. In split-tunnel-konfiguraasje dy't fergeat in prefiks op te nimmen, produsearret krekt it symptoom datst efterfolgest: de applikaasje dy't de tunnel brûke moatte soe, lost en ferbynt ynstee lokaal. Fergelykje de ynstallearre prefiksen mei de bestimmingen dy't de brûker echt nedich hat, net mei de adressen dy'tst tafallich testte. In split-tunnellist dy't de bestânsserver dekt mar net syn oplosser, produsearret in ferbining dy't nei in iepenbier adres oplost en dan net autentisearret, wat op in wachtwurdprobleem liket en in rûteprobleem is.

De bûtenrûte moat ek oerlibje

De tunnel is sels ferkear. De pakketten dy't de ynsletten lading drage, geane oer de fysike ynterface nei it adres fan 'e partner, en dat paad mei net werom yn 'e tunnel rûte wurde. As dat dochs bart, kriest de karakteristike flater wêrby't de tunnel oprjochte wurdt en dan ophâldt ferkear troch te litten, om't it ferfier foar de tunnel no binnen de tunnel sit.

Kontrolearje it partneradres sa'tst de ynderlike bestimming kontrolearre hast, en befêstigje dat it nei de fysike ynterface oplost en net nei de tunnel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

In rekursive rûte, in beliedsregel dy't de partner fangt, of in standertrûte ferfongen troch in folsleine-tunnelklant binne de trije gewoane oarsaken. Alle trije binne sichtber yn 'e bûtenste syktocht, en gjin fan alle is sichtber yn in dump fan 'e haadtabel dy't efterôf nommen is.

Wat routingútfier dy net fertelle kin

In krekte syktocht betsjut dat de kernel it pakket earne sinfol hinne stjoere soe. It betsjut net dat de firewall it tastean, it IPsec-belied it dekt, de NAT-regel it oerset, of de fiere kant in weromrûte hat. Elk dêrfan is in lettere faze, en de strongSwan-notysjes oer trochstjoeren beskriuwe de keatling dy't in pakket oan beide kanten troch moat.

It hâldt ek gjin rekken mei bining op applikaasjenivo. In proses kin him bine oan in ynterface, in mark sette of syn eigen oplosser brûke en ferbine mei in namme dy't oars oplost as watst testte. As de syktocht krekt is en de ferbining dochs mislearret, is de folgjende fraach hokker proses it docht en oft dat proses deselde tabel sjocht as do.

Hâld de diagnoaze dus oardere: neam de bestimming en de boarne, fiere de syktocht út, lês allinnich de tabel en regel dy't de syktocht neamde, en test dan de folgjende faze. Dy folchoarder hâldt in routingûndersyk binnen minuten en lit in ferslach efter dat in oar folgje kin, wat in plakte tabel nea docht.

Relatearre artikelen