Voivatko DHCP-reitit ohjata liikenteesi VPN-tunnelin ohi?

Salaus alkaa rajalta, ja tämä raja on reitityspäätös, jonka päätepiste tekee ennen kuin yhtään pakettia kapseloidaan. Verkko, joka ei näe avaimiasi koskaan, voi silti antaa koneellesi reitin, josta se pitää enemmän kuin tunnelin omasta. Tässä sekoitetaan kaksi vikaa: jo tunnelissa olevan paketin lukeminen ja sellaisen paketin ohjaaminen, jota sinne ei koskaan laitettu.

Ero on merkittävä, koska toinen vika on halvempi järjestää ja paljon helpompi jäädä huomaamatta. Se näkyy pyyntönä, joka lähti väärästä rajapinnasta, kun asiakasohjelma yhä raportoi terveestä yhteydestä.

Kaksi tapaa, joilla verkko voi vaikuttaa sinuun

Tunneliin saapuva paketti pitää hyötykuormansa piilossa jokaiselta ylittämältään hypyltä, ja se suoja pitää myös silloin, kun polku yllättää sinut. Paketti, joka ei koskaan saavu tunneliin, on tavallinen pyyntö osoitteestasi, lähetetty sinne mihin reititystaulu osoitti. Ensimmäinen vika vaatii murtuneen salauksen tai vaarantuneen vastapuolen, kun taas toinen vaatii vain määritysviestin, jota koneesi päätti luottaa. Tämä epäsymmetria on syy siihen, miksi reitityspuoli ansaitsee oman tarkastelunsa.

Polulla oleva laitteisto ei tarvitse avaimiasi vaikuttaakseen toiseen tapaukseen. Se tarvitsee vain sen, että päätepisteesi hyväksyy reitin, resolverin tai käytäntösäännön, joka tuottaa sellaisen.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

Mistä reitti voi tulla ennen kuin tunneli on olemassa

DHCP jakaa enemmän kuin osoitevuokran. Luokattoman staattisen reitin asetus voi kantaa kohde-etuliitteitä ja seuraavia hyppyjä, ja RFC 3442 käsittelee väärän reitittimen osoitteen turvallisuusvaikutuksia: harhautettu liikenne, palvelunesto tai polulle asetettu tarkkailija. Asiakasohjelma, joka hyväksyy nämä reitit ennen kuin tunneli nousee, voi päätyä suosittuun polkuun, jolla ei ole mitään tekemistä palveluntarjoajasi kanssa.

Mikään tästä ei tee reittien syöttämisestä yleistä. Asiakasohjelman on hyväksyttävä asetus, etuliitteen on katettava liikenne, josta välität, valitun seuraavan hypyn on oltava tavoitettavissa ja valvontakäytännön on sallittava paketin lähteä sitä tietä. Poista mikä tahansa näistä, ja sama vastaus on vaaraton. Siksi myös kaksi konetta samassa verkossa voivat käyttäytyä eri tavoin, koska ne eivät aja samaa asiakasohjelmaa, samaa käytäntöä tai edes samaa osoiteperhettä.

IPv6 ansaitsee oman kierroksensa, koska reitittimen ilmoitukset kantavat oletusreittiä eri koodilla kuin DHCPv4-asetus. Testi, joka tutkii vain v4-taulua, ei ole kattanut sitä.

Tarkista polku, jonka ydin todella valitsee

Reittikyselyihin voi vastata, joten kysy niiltä sen sijaan että päättelet tilavalosta. Alla olevat komennot näyttävät valitun reitin ja lähteen yhdelle kohteelle sekä säännöt, jotka voivat ohittaa päätaulun. Suorita ne yhdistettynä ja uudelleen yhteyden palauttamisen jälkeen, koska vuokran uusiminen voi muuttaa vastausta.

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

Lue tulosteesta kahta asiaa: reitissä nimetty rajapinta ja valittu lähdeosoite. Tunnelireitti nimeää tunnelilaitteen, vuotanut reitti fyysisen, ja ero näkyy ilman mitään salauksen purkamista. Jos vastaus muuttuu suoritusten välillä, säilytä molemmat tulosteet ja vertaa säännöt, jotka ne tuottivat.

Älä pysähdy oletusreittiin. Sovelluspoikkeus, jaetun tunnelin etuliite tai toinen käytäntösääntö voi viedä tietyn kohteen tunnelin ympäri, kun oletus osoittaa yhä sisään.

Päätä, missä valvonnan pitäisi olla

Kolme ehtoa ratkaisee, riittääkö asiakaspuolen valvonta vai tarvitsetko jotain sen ulkopuolelta. Jos asiakasohjelma asentaa ja puolustaa reitit jokaiselle käyttämällesi osoiteperheelle, oletusreitin omistava tunneli on yleensä riittävä. Jos koneen on päästävä paikallisiin resursseihin, kun kaikki muu pysyy tunnelissa, ne poikkeukset on lueteltava ja omistettava sen sijaan, että ne jätetään liityntäverkon ilmoittaman varaan. Ja jos alusta voi sitoa liikenteen rajapintaan sovelluskohtaisesti, se sidonta on vahvempi tae kuin reitti, jonka mikä tahansa voi ohittaa.

Minkä tahansa valitsetkin, kirjoita päätös sinne, missä määritys elää. Sääntö, joka on olemassa siksi, että joku kirjoitti sen tapahtuman aikana, ei selviä seuraavasta uudelleenkäynnistyksestä, joten pidä paikalliset ja käynnistyksen poikkeukset kapeina ja kirjaa, miksi kukin niistä on olemassa.

Suorita haku-komennot uudelleen jokaisen asiakaspäivityksen ja verkkomuutoksen jälkeen ja vertaa viimeksi tallennettuun tulosteeseen. Reititystaulu on valvonnan raja, joten kohtele sitä sellaisena.