Ĉu DHCP-itineroj povas sendi vian trafikon ĉirkaŭ la VPN-tunelo?

Ĉifrado komenciĝas ĉe limo, kaj tiu limo estas itinera decido, kiun la finpunkto faras antaŭ ol iu ajn paketo estas enkapsuligita. Reto, kiu neniam vidas viajn ŝlosilojn, tamen povas doni al via maŝino itineron, kiun ĝi preferas al tiu de la tunelo mem. Ĉi tie konfuziĝas du fiaskoj: legi paketon jam ene de la tunelo, kaj direkti paketon, kiu neniam estis metita tien.

La distingo gravas ĉar la dua fiasko estas pli malmultekosta aranĝi kaj multe pli facile preteratenti. Ĝi montriĝas kiel peto, kiu eliris tra la malĝusta interfaco dum la kliento ankoraŭ raportis sanan konekton.

Du manieroj, kiel reto povas efiki vin

Paketo, kiu atingas la tunelon, havas sian utilan ŝarĝon kaŝitan de ĉiu salto, kiun ĝi trapasas, kaj tiu protekto teniĝas eĉ kiam la vojo surprizas vin. Paketo, kiu neniam atingas la tunelon, estas ordinara peto de via adreso, sendita tien, kien montris la itinera tabelo. La unua fiasko bezonas rompitan ĉifron aŭ kompromititan samtavolan, dum la dua bezonas nur agordan mesaĝon, kiun via maŝino decidis fidi. Tiu malsimetrio estas kial la duono pri itinerado meritas propran revizion.

Ekipaĵo survoje ne bezonas viajn ŝlosilojn por influi la duan kazon. Ĝi bezonas nur, ke via finpunkto akceptu itineron, solvilon aŭ politikan regulon, kiu produktas unu.

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

De kie itinero povas veni antaŭ ol la tunelo ekzistas

DHCP disdonas pli ol adresprunton. La opcio pri senklasa statika itinero povas porti celprefiksojn kaj sekvajn saltojn, kaj RFC 3442 diskutas la sekurecajn konsekvencojn de malĝusta enkursiga adreso: misdirektita trafiko, malakcepto de servo, aŭ observanto lokita survoje. Kliento, kiu akceptas tiujn itinerojn antaŭ ol la tunelo leviĝas, povas fini kun preferata vojo, kiu havas nenion komunan kun via provizanto.

Nenio el tio faras itineran enĵeton universala. La kliento devas akcepti la opcion, la prefikso devas kovri la trafikon, pri kiu vi zorgas, la elektita sekva salto devas esti atingebla, kaj la plenum-politiko devas permesi al la paketo eliri tiumaniere. Forigu iun ajn el tiuj kaj la sama respondo estas sendanĝera. Tial ankaŭ du maŝinoj en unu reto povas konduti malsame, ĉar ili ne rulas la saman klienton, la saman politikon, aŭ eĉ la saman adresan familion.

IPv6 meritas propran trairon, ĉar enkursigilaj anoncoj portas aprioran itineron per malsama kodo ol la opcio DHCPv4. Testo, kiu inspektas nur la tabelon v4, ne kovris ĝin.

Kontrolu la vojon, kiun la kerno fakte elektas

Itineraj serĉoj estas respondeblaj, do demandu ilin anstataŭ konkludi el statusa lumo. La subaj komandoj montras la elektitan itineron kaj fonton por unu celo, kune kun la reguloj, kiuj povas superi la ĉefan tabelon. Rulu ilin dum vi estas konektita kaj denove post rekonekto, ĉar pruntonovigo povas ŝanĝi la respondon.

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

Legu la eligon por du aferoj: la interfaco nomita en la itinero kaj la elektita fontadreso. Tunela itinero nomas la tunelan aparaton, likinta itinero nomas la fizikan, kaj la diferenco videblas sen malĉifri ion ajn. Se la respondo ŝanĝiĝas inter ruloj, konservu ambaŭ eligojn kaj komparu la regulojn, kiuj produktis ilin.

Ne haltu ĉe la apriora itinero. Aplikaĵa escepto, split-tunela prefikso aŭ dua politika regulo povas porti specifan celon ĉirkaŭ la tunelo dum la aprioro ankoraŭ montras enen.

Decidu, kie la plenumo devas loĝi

Tri kondiĉoj decidas, ĉu plenumo ĉe la klienta flanko sufiĉas aŭ ĉu vi bezonas ion ekster ĝi. Se la kliento instalas kaj defendas itinerojn por ĉiu adresa familio, kiun vi uzas, tunelo, kiu posedas la aprioran itineron, kutime sufiĉas. Se la maŝino devas atingi lokajn rimedojn dum ĉio alia restas en la tunelo, tiuj esceptoj devas esti listigitaj kaj posedataj anstataŭ lasitaj al tio, kion anoncis la alira reto. Kaj se la platformo povas ligi trafikon al interfaco po aplikaĵo, tiu ligo estas pli forta garantio ol itinero, kiun io ajn povas superi.

Kion ajn vi elektos, skribu la decidon tie, kie loĝas la agordo. Regulo, kiu ekzistas ĉar iu tajpis ĝin dum incidento, ne postvivos la sekvan restartigon, do tenu lokajn esceptojn kaj praŝarĝajn esceptojn mallarĝaj kaj notu, kial ĉiu ekzistas.

Rerulu la serĉkomandojn post ĉiu klienta ĝisdatigo kaj ĉiu reta ŝanĝo, kaj komparu kun la laste registrita eligo. La itinera tabelo estas la plenum-limo, do traktu ĝin kiel tian.