Miksi yksi aliverkko ohittaa yhä VPN:n oletusreitin

Vaihdat VPN:n täystunneliin, suurin osa liikenteestä tottelee, ja sitten yksi osoite vastaa suoraan — tulostin, NAS, hyppykone osoitteessa 10.x. Ilmeinen tulkinta on, että tunneli vuotaa, joten lasket oletusreitin metriikkaa eikä mikään muutu. Se epäonnistunut yritys on vihje: oletusreitti on varavaihtoehto, ei tuomio. Reitinhaku ottaa pisimmän täsmäävän etuliitteen ennen kuin se edes vertaa metriikoita, joten /24 voittaa /0:n riippumatta siitä, minkä luvun kumpaankin liität. Kun tämä järjestys on selvä, vuoto on yleensä reitti, jonka joku asensi tarkoituksella, tai etuliite, jota asiakas ei koskaan aikonut kattaa.

Mitä oletusreitti oikeastaan lupaa

0.0.0.0/0 täsmää jokaiseen IPv4-kohteeseen nollalla bitillä spesifisyyttä. Se on olemassa, jotta isäntä voi tavoittaa kaiken, mitä sen taulukko ei kuvaa paremmin. Reitti 192.168.1.0/24:ään kantaa 24 täsmäävää bittiä, joten kohteelle 192.168.1.40 se voittaa ennen kuin kukaan vertaa metriikoita, hallinnollista etäisyyttä tai miksi asiakas prioriteettikenttäänsä kutsuukaan. Sama sääntö pätee Linuxin FIB:ssä, Windowsin reititystaulukossa ja macOS:n takana olevassa BSD-pinossa.

Tavallisessa lähiverkossa tämä käytös on ominaisuus. Paikallinen aliverkko on suoraan kytketty, tulostin toimii edelleen samalla kun tunneli kantaa selaamisesi, eikä mikään ole väärin määritetty. Kysymys, joka kannattaa esittää, ei ole, miksi se yksi osoite menee suoraan, vaan mikä etuliite missä taulukossa täsmää siihen ja kuka sen sinne laittoi.

Puolikkaat oletusreitit eli miksi oletusmerkintä voi näyttää koskemattomalta

Selkein esimerkki on redirect-gateway def1 OpenVPN:ssä. Sen sijaan että se poistaisi oletusreittisi ja korvaisi sen, se lisää 0.0.0.0/1:n ja 128.0.0.0/1:n. Yhdessä pari kattaa koko IPv4:n, jokainen etuliite on pidempi kuin /0, ja molemmat voittavat reitittimen oletusreitin jättäen sen paikalleen. Aja sen jälkeen reittilistaus, ja alkuperäinen oletusreitti on yhä siellä, osoittaa yhä yhdyskäytävääsi; sitä ei vain koskaan valita internet-kohteille.

WireGuardin wg-quick saavuttaa saman tuloksen käytäntöpohjaisella reitityksellä. Kun AllowedIPs kattaa 0.0.0.0/0:n, se luo oman taulukkonsa, lähettää merkityt paketit sinne ja lisää säännön, joka jättää huomiotta päätaulukon nollan pituisen etuliitteen. Päätaulukko pitää oletusmerkintänsä, ja säännöt päättävät, että rajapinnan omistaman liikenteen kohdalla kysytään ensin tunnelitaulukkoa.

Molemmat mallit tarvitsevat täsmälleen yhden reitin tunnelin ulkopuolelle: isäntäreitin VPN-palvelimen omaan osoitteeseen alkuperäisen yhdyskäytävän kautta. Ilman sitä asiakas yrittäisi kantaa tunnelia rakentavat paketit tunnelin sisällä, eikä yhteys koskaan valmistuisi. Siksi tunneliton reitti taulukossasi on normaali jopa tiukassa täystunneliprofiilissa. Reitit, jotka kannattaa kyseenalaistaa, ovat ne, jotka kattavat kohteita, joista todella välität.

Metriikat ratkaisevat tasapelit, etuliitteet ratkaisevat voittajat

Metriikoita verrataan vain ehdokkaiden kesken, jotka täsmäävät kohteeseen yhtä hyvin. Linuxissa ip route get 10.20.5.9 tulostaa voittajan taulukoineen, ja ip route show table all luettelee ehdokkaat, mukaan lukien mahdolliset puolikkaat oletusreitit ja minkä tahansa taulukon, johon sääntö osoittaa. Windowsissa Find-NetRoute -RemoteIPAddress 10.20.5.9 palauttaa valitun reitin ja lähdeosoitteen, kun taas Get-NetRoute näyttää raakataulukon — mutta tehokas kustannus on reitin metriikka plus rajapinnan metriikka, joten hidas sovitin voi hävitä tasapelin, jonka näyttää voittavan.

Kolme tapausta kattaa suurimman osan siitä, mitä näet:

• Sama kohde, /24 vastaan /0: /24 voittaa etuliitteen pituudella, mitä metriikat sanovatkaan.
• Sama kohde, kaksi /24:tä eri metriikoilla: alempi tehokas metriikka voittaa.
• Sama kohde, kaksi taulukkoa, yksi käytäntösäännön valitsema: sääntö valitsee taulukon ensin, ja etuliitteiden vertailu tapahtuu sen sisällä.

Kolmas tapaus on se, mihin useimmat näistä raporteista päätyvät. Linuxin ip rule tai Windowsin VPN-liikennesuodatin voi lähettää liikennettä taulukkoon, jossa ei koskaan ollut tunnelin oletusreittiä, ja päätaulukko näyttää koko ajan täydelliseltä.

Kuka yleensä omistaa ohituksen

Aloita profiilista, älä taulukosta. Split-tunnel-määritykset ja sovelluskohtaiset VPN-asetukset jättävät nimetyt etuliitteet tarkoituksella tunnelin ulkopuolelle; työprofiili, joka suojaa yhtä yksityistä aliverkkoa ja päästää yleisen selaamisen suoraan, käyttäytyy suunnitellusti, ja sen ohittaminen rikkoo käytännön, jonka se oli tarkoitettu toteuttamaan. Microsoftin VPN-reititysohje vetää saman rajan pakotetun tunneliliikenteen ja selkeiden poikkeusten välille, mikä tekee siitä hyödyllisen ristitarkistuksen ennen kuin muutat mitään.

Etsi seuraavaksi jäänteitä. Reitti, joka osoittaa rajapintaan, jota ei enää ole, tai edellisen verkon osoitteeseen, ilmestyy sen jälkeen, kun telakointiasemat, USB-sovittimet ja konttisillat tulevat ja menevät. Sen kerran poistaminen ei ole loppu: NetworkManagerin yhteysprofiilit, netplan-tiedostot ja Windowsin pysyvät reitit asentavat sen uudelleen seuraavalla yhdistämisellä tai käynnistyksellä, joten etsi tiedosto tai profiili, joka sen omistaa, ennen kuin muutat mitään.

Tarkista sitten IPv6 erikseen. ip -6 route ja Get-NetRoute -AddressFamily IPv6 pitävät erillistä tilaa, erillisiä oletusreittejä ja erillistä asiakaskäyttäytymistä. Pelkän IPv4:n tarkastus ei kerro mitään kaksoispinon isännästä, joka hiljaa suosii natiivia IPv6-polkua, ja se yksin voi saada asiakkaan näyttämään split-tunnelilta.

Vahvista sovelluksen omalla kululla

Kirjaa kohde, jota sovellus todella käyttää, ja kysy sitten järjestelmältä polku, jonka se kulkisi lähdeosoitteesta, johon kyseinen sovellus sitoutuu. ip route get 10.20.5.9 from 192.168.1.40 vastaa siihen Linuxissa; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus paikallinen osoite tekee sen Windowsissa. Vertaa tulosta siihen, mitä profiili väittää. Selaimen julkinen IP-sivu testaa yhtä kohdetta yhdellä protokollalla eikä kerro mitään yksityisestä osoitteesta, joka valituksen aloitti.

Korjaa kapein objekti, joka selittää eron. Jos poikkeus on hyväksytty, kirjoita etuliite muistiin ja jätä se rauhaan; jos ei, poista reitti tai lisää selkeä kapeampi reitti tunnelin kautta sen sijaan, että laskisit oletusreitin metriikkaa. Metriikan laskeminen ei voi ohittaa pidempää etuliitettä, eikä oletusreitin muokkaaminen, kun kaksi /1-reittiä omistaa internetpolun, muuta mitään.

Yhdistä sitten tunneli uudelleen ja toista sama kysely. Asiakkaat asentavat reitit uudelleen joka yhdistämiskerralla, joten muutos, joka kestää vain seuraavaan kättelyyn, ei ole testattu. Jos polku poikkeaa yhä, jäljellä olevat epäillyt ovat käytäntösääntö, toinen taulukko tai asiakaspuolen suodatin — ei oletusreitti.

• Nimeä kohde ja lähdeosoite, joita sovellus todella käyttää.
• Näytä voittava reitti komennolla ip route get tai Find-NetRoute.
• Tarkista, omistaako internetpolun /1-pari vai käytäntötaulukko.
• Luettele jokainen /0:aa pidempi etuliite, joka täsmää kohteeseen.
• Toista IPv6-tarkistus erikseen.
• Jäljitä jäljelle jäänyt reitti takaisin tiedostoon, profiiliin tai suodattimeen, joka sen asentaa.
• Yhdistä uudelleen ja aja kysely uudelleen ennen kuin kutsut sitä korjatuksi.

Jos kaikki seitsemän ovat profiilin kanssa samaa mieltä, tunneli tekee täsmälleen sen, mitä varten se määritettiin, ja korjaus kuuluu profiiliin, ei metriikkaan.