Miten erottaa VPN:n työntämät reitit staattisista Linuxissa

Kannettavaan ilmestyy etuliite, kun tunneli nousee, joten tuntuu kuin VPN olisi asentanut sen. Ehkä asensikin, mutta sama tulos voi tulla yhteyden muodostuksessa ajettavasta asiakasskriptistä, aliverkon listaavasta yhteysprofiilista tai staattisesta reitistä, joka oli siellä koko ajan ja alkoi toimia vasta kun rajapinta oli olemassa. Väärän omistajan valitseminen tarkoittaa, että reitti palaa jokaisen siivouksen jälkeen ja seuraava henkilö toistaa saman korjauksen. Alla oleva järjestys erottaa nämä kolme ennen kuin mitään muutetaan.

Vaihe 1: nimeä mekanismi, joka asentaa etuliitteet

Eri protokollat tarjoavat tavoitettavuutta eri tavoin, ja kaiken kutsuminen ilmoitukseksi kätkee eron. OpenVPN-palvelin työntää reittidirektiivin ohjauskanavan kautta ja asiakas asentaa sen, ellei pull-suodatin estä sitä. WireGuard-määritys luettelee sallitut etuliitteet paikallisesti, ja asiakas käyttää niitä sekä salausavainten reititykseen että lisäämiinsä reitteihin. IPsec-tunneli sopii liikenteen valitsimista vastapuolen kanssa, ja ydin asentaa reitit näistä valitsimista.

Selvitä, mitä näistä tunnelisi käyttää, ennen kuin luet mitään taulukkoa. Yhteyden aikana työnnetty reitti ei ole reititysprotokollan ilmoitus eikä lupaa, että etuliite on tavoitettavissa kaukokään takana. Merkitse mekanismi etuliitteen viereen, koska se ratkaisee, mihin korjaus kuuluu.

Vaihe 2: vertaa taulukkoa yhteyden yli

Tallenna päätaulukko tunneli alhaalla, nosta se, tallenna uudelleen ja vertaa kahta tallennetta. Kaikki ilmestynyt kuuluu yhteyden elinkaareen, ja kaikki paikalleen jäänyt kuuluu paikalliseen määritykseen.

Tallenna se komennolla ip route show table main > /tmp/route-down.txt, yhdistä ja tallenna uudelleen. Tee sama komennolle ip -6 route, jos sivusto käyttää IPv6:ta, koska puuttuva etuliite siellä tuottaa vikoja, jotka näyttävät liittymättömiltä reititykseen.

Vaihe 3: lue metriikka, älä vain läsnäoloa

Kaksi merkintää samalle etuliitteelle voivat olla olemassa yhtä aikaa, ja ydin valitsee pienemmän metriikan. Staattinen reitti metriikalla 50 voittaa jatkossakin työnnetyn reitin metriikalla 100, vaikka molemmat ovat näkyvissä, siksi 'reitti on siellä' ja 'liikenne käyttää sitä' ovat eri väitteitä.

Kysy ytimeltä suoraan komennolla ip route get 10.20.5.7 ja lue rajapinta, jonka se ilmoittaa. Jos liikenne lähtee fyysisen sovittimen kautta samalla kun tunnelireitti istuu taulukossa, metriikka tai etuliitteen pituus selittää sen, ei VPN-asiakas. Toista haku isännälle, jonka tiedät olevan tunnelin takana, ja sellaiselle, jonka tiedät ettei ole, ja ero näyttää, käyttäytyykö jako tarkoitetusti.

Vaihe 4: löydä merkinnät, jotka elävät tunnelia pidempään

Staattiset reitit selviävät katkaisusta suunnittelun mukaan, ja sieltä vanhentuneet merkinnät tulevat. Pysyvä reitti rajapintaan, jota ei enää ole, voi niellä aliverkon hiljaa, ja uudelleenkäytettyyn rajapintanimeen osoittava reitti voi uudelleenkäynnistyksen jälkeen lähettää yksityistä liikennettä väärästä ovesta.

Tarkista pysyvä puoli paikasta, jota jakelusi käyttää, oli se sitten systemd-networkd-yksikkö, NetworkManager-profiili tai skripti asiakkaan up-hakemistossa. Elävän taulukon korjaaminen komennolla ip route del kestää vain seuraavaan yhteyteen. Käsittele sitä poistoa hypoteesin testinä, älä korjauksena.

Kun kaukopää tarjoaa väärän kattavuuden, vie asia operaattorille sen sijaan että suodattaisit kaiken. Kaikkien työnnettyjen asetusten hylkääminen hylkää myös DNS:n ja jaetun tunnelin käytännön, joista profiili riippuu.

Vaihe 5: vahvista paluupolku ennen kuin syytät asiakasta

Sivusto-sivusto-yhteydessä tai tunnelin takana olevassa aliverkossa kaukopää tarvitsee reitin takaisin asiakasosoitteeseesi ja edelleenlähetyksen käyttöön yhdyskäytävässä. Yksisuuntainen polku näyttää täsmälleen asiakkaan reititysvirheeltä, paitsi että kättely ja lähtevä paketti onnistuvat molemmat.

Käänteisen polun suodatus lisää toisen ansan Linux-yhdyskäytäviin. Vastaus, joka saapuu eri rajapintaan kuin reitti ennustaa, pudotetaan tiukassa tilassa, ja epäsymmetriset polut kahden operaattorin kautta laukaisevat sen luotettavasti. Pudotuslaskurit yhdyskäytävässä, ei asiakkaassa, kertovat, onko suodatus syy.

Vaihe 6: testaa resurssia, älä pingiä

Kun valittu reitti on oikein, avaa varsinainen resurssi ja vahvista paluuliikenne. Ping-vastaus todistaa polun yhteen suuntaan eikä mitään palvelusta, ja välimuistiin tallennetulla yhteydellä vastaava palvelu todistaa vielä vähemmän.

Toista sitten koko tarkistus uudelleenyhdistämisen jälkeen. Järjestyksen arvo on siinä, että se ennustaa, mitä seuraava yhteys tekee, siksi sekä vertailu että metriikka kuuluvat tikettiin.