Miksi VPN-reitti ei näytä yhdyskäytävää ip route -tulosteessa
Rivi, jossa on laite mutta ei yhdyskäytävää, on suora reitti, ei rikkinäinen. Lue kohde, dev ja scope ja vahvista sitten komennolla ip route get.
Reititystaulut luetaan rikkinäisiksi aina, kun yhdyskäytävä sarake jää tyhjäksi, vaikka rivi on yleensä sellaisenaan täydellinen. Kenttä via näkyy vain silloin, kun ydin luovuttaa paketin seuraavan hypyn osoitteelle; liitäntään kiinnittynyt reitti saavuttaa kohteensa sen sijaan linkkikerroksen selvityksen tai piste-piste-vertaisparin kautta. Sarakkeiden lukeminen vasemmalta oikealle kertoo, missä tapauksessa olet, ja se lukeminen pitäisi tehdä ennen kuin kukaan muokkaa oletusreittiä. Useimmat puuttuvaa yhdyskäytävää koskevat tiketit päättyvät tähän eroon.
Lue reittirivi sarake sarakkeelta
Jokainen merkintä alkaa kohteella ja sen etuliitteen pituudella ja lisää sitten muuntimia kiinteässä sanastossa: via, dev, proto, scope, src ja metric. Rivi kuten 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 on tiivis mutta täysin määritelty. Siitä ei puutu mitään, eikä siinä vihjata mitään reitittimen osoitetta.
Mielenkiintoinen osa on via:n puuttuminen. Ilman seuraavaa hyppyä ydin selvittää kohteen suoraan nimetyllä liitännällä, mikä tunnelin kohdalla tarkoittaa kehyksen luovuttamista tunnelilaitteelle ja kapseloinnin jättämistä sen huoleksi. proto kernel kirjaa, että merkintä asennettiin automaattisesti osoitteen yhteydessä, ei ylläpitäjän kirjoittamana. scope link kertoo, että kohde on tavoitettavissa tällä linkillä ilman reitittimen kautta kulkemista, ja src nimeää osoitteen, jota ydin suosii täsmäävän liikenteen lähteenä.
Lue nyt oletusreitti samalla tavalla: default via 192.0.2.254 dev eth0 proto static metric 100. Tässä via on läsnä, koska paketti todella tarvitsee seuraavan hypyn, ja sen hypyn on itsessään oltava tavoitettavissa eth0:n kautta. Nämä kaksi riviä eivät ole toistensa muunnelmia; ne vastaavat eri kysymyksiin siitä, mihin liikenne menee.
Kaksi reittimuotoa, jotka sekoitetaan keskenään
Tunnelin aliverkkoreitti ja oletusreitti näyttävät kuvakaappauksessa samankaltaisilta ja käyttäytyvät täysin eri tavalla. Käytä alla olevaa taulukkoa kenttien lukemisen apuna ja vahvista sitten todelliset luvut koneella, jota vianmäärityksessä tutkit, sen sijaan että luottaisit oppaasta otettuun esimerkkiin.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
Se, mitä taulukko ei voi kertoa, on aikomus. Suora reitti yksityiseen alueeseen tunnelin kautta on tarkoituksellinen jaetun tunnelin suunnittelu; sama muoto isännällä, jonka pitäisi lähettää kaikki VPN:n kautta, on oire. Aikomus elää siinä määrityksessä, joka merkinnän tuotti, joten katso työkalua, joka sen asensi, ennen kuin päättelet ytimen tehneen jotain väärin.
Samoin puuttuva yhdyskäytävä ei ole lupa keksiä sellaista. Jos reitti todella tarvitsee seuraavan hypyn, sen hypyn on oltava tavoitettavissa liitännällä, joka sen kuljettaa, ja piste-piste-tunnelissa vertaisparin osoite ei ole sama objekti kuin paikallinen osoite. Paikallisen tunneliosoitteen kohteleminen Ethernet-reitittimenä on tavallinen tapa tuottaa reitti, joka näyttää oikealta eikä välitä mitään.
Kysy ytimeltä, mitä riviä se todella käyttää
Taulukon lukeminen ei ole sama kuin haun suorittaminen, koska ydin tarkistaa käytäntösäännöt, useita taulukoita ja välimuistiin tallennetut merkinnät ennen vastaamistaan. Verbi, joka suorittaa varsinaisen haun, on ip route get, ja se tulostaa reitin, jonka paketti noilla ominaisuuksilla kulkisi.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Vaihda tilalle kohde, joka sinua todella kiinnostaa, ja lisää sitten from tai iif, kun liikenne valitaan lähteen perusteella tai välitetään edelleen, koska tavallinen paikallinen haku voi valita eri polun kuin edelleen välitetty asiakas. Vastaus nimeää liitännän, valitun lähdeosoitteen ja mahdollisen seuraavan hypyn, mikä on samat tiedot, joilla paketti sillä hetkellä reititettäisiin.
Jos vastaus yllättää sinut, tulosta säännöt ennen minkään muuttamista: ip -4 rule show luettelee ne prioriteettijärjestyksessä, eikä VPN-asiakas, joka asentaa oman taulukkonsa tai merkittyjä paketteja koskevan säännön, näy päätaulukossa lainkaan. Kaikkien taulukoiden luetteleminen sulkee tuon aukon.
ip -4 route show table all | grep -E 'tun|default'Tarkista alusta ennen kuin korvaat oletusreitin
Tunnelin omien pakettien on päästävä etäpäätepisteeseen, ja ne tekevät sen fyysisen liitännän kautta käyttäen reittiä, joka oli olemassa ennen VPN:n nousua. Koko oletusreitin korvaaminen kiinnittämättä tuota päätepistettä lähettää kapseloidut paketit siihen tunneliin, joka niiden pitäisi rakentaa, ja yhteys romahtaa. Vahvista ensin päätepisteen polku hakemalla pelkästään sen osoitetta.
Pidä kolme asiaa erillään, kun teet muutoksen: päätepisteen reitti, jonka on jäätävä fyysiselle liitännälle, yksityiset alueet, joiden pitäisi mennä tunneliin, ja oletusreitti, joka päättää kaikesta muusta. Erottele ne tässä järjestyksessä, ota yksi kerrallaan käyttöön ja suorita haku uudelleen jokaisen vaiheen jälkeen. Epäonnistunut ping todistaa jälkikäteen itsessään hyvin vähän, sillä käyttöoikeudet, vastausten reititys, DNS ja itse palvelu ovat kaikki oikean reitin alavirrassa.
Kirjoita muistiin neljä arvoa, jotka rivi antoi sinulle ennen muokkausta: kohde, seuraava hyppy tai sen puuttuminen, laite ja valittu lähde. Jos myöhempi muutos siirtää mitä tahansa niistä, tiedät, mitä päätöstä todella muutettiin, ja voit palauttaa yhden merkinnän sen sijaan että arvaisit koko taulukkoa.