Reititystaulukko vai todellinen haku: minne VPN-liikenne menee

Reititystaulukon vedos on vähiten hyödyllinen diagnostiikka VPN-ongelmien selvittämisessä ja yleisimmin liitetty. Neljäkymmentä riviä etuliitteitä kertoo, mitä kone voisi tehdä, ei sitä, mitä se teki epäonnistuneelle pyynnölle. Mekanismi, jonka todella haluat, on haku: kun lähde ja kohde ovat nämä, mikä sääntö täsmäsi, mitä taulukkoa kysyttiin ja mikä käyttöliittymä ja seuraava hyppy tulivat ulos. Aloita yhdestä kohteesta ja yhdestä lähteestä, lue sitten taulukkoa kysymys mielessäsi, ja sama tuloste muuttuu kohinasta todisteeksi.

Taulukko on joukko ehdokkaita, ei päätös

Jokainen merkintä kuvaa etuliitteen ja sen, mitä sille täsmäävälle liikenteelle tehdään: lähetä se käyttöliittymään, luovuta seuraavalle hypylle tai hylkää. Mikään luettelossa ei ole järjestetty tarkoituksen mukaan, eikä ihmiselle tarkimmalta näyttävä merkintä ole aina se, jonka ydin valitsee, koska valinta noudattaa pisintä etuliiteosumaa ja yhtäläisten etuliitteiden kohdalla metriikkaa.

Ensimmäinen askel on siis kysyä ytimeltä luettelon lukemisen sijaan. Hakukomento vastaa kohteelle, ja lähdeargumentin kanssa se vastaa täsmälleen sille parille, jota edelleen välitetty tai sidottu yhteys käyttäisi:

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

Jokainen yllä oleva osoite on dokumentaatioesimerkki. Kyse on vastauksen muodosta: käyttöliittymä, valittu lähdeosoite, yhdyskäytävä ja taulukko, josta merkintä tuli. Jos tuloste ei vastaa odottamaasi käyttöliittymää, olet paikantanut ongelman yhdellä komennolla, eikä täyden taulukon lukeminen olisi kertonut, mikä ehdokas voitti.

Haku kulkee ensin säännöt, sitten taulukot

Linuxissa päätös on kaksivaiheinen. Politikkasäännöt arvioidaan prioriteettijärjestyksessä, ja ensimmäinen täsmäävä sääntö nimeää kysyttävän taulukon; se taulukko tekee sitten pisimmän etuliiteosuman. Sääntö voi täsmätä lähteen, kohteen, palomuurimerkin, käyttöliittymän tai yhdistelmän perusteella, minkä vuoksi päätaulukon vedos voi olla täysin tarkka ja täysin merkityksetön tutkimallesi paketille.

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

Jos sääntö lähettää liikennettä VPN-altaastasi taulukkoon 100, silloin taulukko 100 on ratkaiseva, ja päätaulukko on houkutin. Tämä on myös lähdeperusteisen reitityksen mekanismi reitittimellä: samalla kohteella voi olla kaksi eri vastausta riippuen siitä, mistä paketti tuli, ja vain lähdeargumentilla tehty haku paljastaa, kumpi pätee.

IPv6:lla on omat sääntönsä ja taulukkonsa. Molempia perheitä ajavat suunnitelmat tarvitsevat molemmat haut, eikä toimiva IPv4-vastaus kerro mitään v6-polusta, jota kaksoispinon asiakas voi suosia.

Mitä VPN-asiakas asentaa

Asiakkaat eivät yleensä korvaa oletusreittiä, koska se rikkoisi tunnelin oman ulkoisen polun. Ne asentavat jotain tarkempaa, joka voittaa etuliitteen pituudella: pari puoliolettusreittejä, jotka kattavat 0.0.0.0/1 ja 128.0.0.0/1, on klassinen temppu, koska molemmat ovat pidempiä etuliitteitä kuin 0.0.0.0/0 ja yhdessä kattavat koko avaruuden. Toiset asentavat tiettyjä yksityisiä etuliitteitä sekä politiikkasäännön, ja jotkut lisäävät merkin, jotta vain valittu liikenne siepataan.

Siksi "VPN ei muuttanut oletusreittiäni" ei ole todiste epäonnistumisesta. Tarkista, mitä se todella lisäsi, ja putoaako kyseinen kohde noiden etuliitteiden sisään:

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

Kaksi puolireittiä jää helposti huomaamatta vedoksesta, koska ne eivät näytä oletusreitiltä. Split-tunnel-kokoonpano, joka unohti sisällyttää etuliitteen, tuottaa täsmälleen sen oireen, jota jahtaat: sovellus, jonka pitäisi käyttää tunnelia, selvittää ja yhdistää sen sijaan paikallisesti. Vertaa asennettuja etuliitteitä kohteisiin, joita käyttäjä todella tarvitsee, älä osoitteisiin, joita satuit testaamaan. Split-tunnel-luettelo, joka kattaa tiedostopalvelimen mutta ei sen selvittäjää, tuottaa yhteyden, joka selvittää julkiseksi osoitteeksi ja epäonnistuu sitten todennuksessa, mikä näyttää salasanaongelmalta ja on reittiongelma.

Ulkoisen reitin on myös selvittävä

Tunneli on itse liikennettä. Kapseloidun hyötykuorman kuljettavat paketit menevät vertaisosoitteeseen fyysisen käyttöliittymän kautta, eikä sitä polkua saa reitittää takaisin tunneliin. Kun se tehdään, syntyy tunnusomainen vika, jossa tunneli muodostuu ja lakkaa sitten välittämästä liikennettä, koska tunnelin kuljetus on nyt tunnelin sisällä.

Tarkista vertaisosoite samalla tavalla kuin tarkistit sisäisen kohteen ja varmista, että se selvittää fyysiseen käyttöliittymään eikä tunneliin:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rekursiivinen reitti, vertaisen sieppaava politiikkasääntö tai täystunnelin asiakkaan korvaama oletusreitti ovat kolme tavallista syytä. Kaikki kolme näkyvät ulkoisessa haussa, eikä mikään niistä näy jälkikäteen otetussa päätaulukon vedoksessa.

Mitä reitityksen tuloste ei voi kertoa

Oikea haku tarkoittaa, että ydin lähettäisi paketin järkevään paikkaan. Se ei tarkoita, että palomuuri sallii sen, IPsec-käytäntö kattaa sen, NAT-sääntö kääntää sen tai että etäpäässä on paluureitti. Jokainen niistä on myöhempi vaihe, ja strongSwanin välitystä koskevat huomautukset kuvaavat ketjun, jonka paketti joutuu kulkemaan molemmissa päissä.

Se ei myöskään huomioi sovellustason sidontaa. Prosessi voi sitoa käyttöliittymään, asettaa merkin tai käyttää omaa selvittäjäänsä ja yhdistää nimellä, joka selvittää eri tavalla kuin testasit. Kun haku on oikein ja yhteys silti epäonnistuu, seuraava kysymys on, mikä prosessi sen tekee ja näkeekö se prosessi saman taulukon kuin sinä.

Pidä siis diagnoosi järjestyksessä: nimeä kohde ja lähde, suorita haku, lue vain se taulukko ja sääntö, jonka haku nimesi, ja testaa sitten seuraava vaihe. Tämä järjestys pitää reititystutkimuksen minuuteissa ja jättää merkinnän, jota toinen voi seurata, mitä liitetty taulukko ei koskaan tee.