Cum să trimiți o singură destinație IPv4 în afara unui tunel OpenVPN

Majoritatea configurațiilor cu tunel complet trimit fiecare pachet prin VPN, iar directiva redirect-gateway este cea care face acest lucru posibil. O singură destinație poate fi totuși exceptată. Adăugarea unei rute de gazdă pentru acea adresă cu substituentul net_gateway îi spune clientului să o atingă prin gateway-ul original al mașinii, în timp ce tot restul continuă să folosească tunelul.

Linia pare inofensivă și adesea chiar este, dar rezolvă o singură întrebare: unde merg pachetele pentru exact acea adresă IPv4. Nu schimbă DNS, IPv6, politica firewall-ului sau ce proces a deschis conexiunea, iar fiecare dintre acestea poate anula excepția în tăcere.

Ce numește de fapt net_gateway

Intrarea din profil pentru acea excepție este o singură linie: route 198.51.100.77 255.255.255.255 net_gateway. Prima adresă este un substituent de documentație pentru destinație, masca o transformă într-o rută către o singură gazdă, iar ultimul token numește substituentul gateway-ului. OpenVPN rezolvă substituenții gateway atunci când instalează rute. vpn_gateway înseamnă gateway-ul propriu al tunelului, partea îndepărtată a legăturii VPN. net_gateway înseamnă gateway-ul implicit pe care gazda îl avea înainte ca VPN-ul să schimbe ceva, care este de obicei routerul local din rețeaua fizică.

Un al treilea substituent, remote_host, se referă la adresa serverului VPN și există pentru ca tunelul să poată ajunge la server pe calea fizică. Confundarea acestor trei este cel mai frecvent motiv pentru care o excepție ajunge în locul greșit sau nu se instalează deloc.

Valoarea este citită la momentul conectării, nu este scrisă în fișier. Dacă mașina se mută în altă rețea, gateway-ul dinaintea VPN-ului se schimbă și ruta urmează noul gateway. Asta este de obicei ceea ce doriți, dar înseamnă și că comportamentul excepției depinde de rețeaua de la care a pornit clientul.

De ce o rută de gazdă învinge ruta implicită a tunelului

Rutarea este decisă de cel mai specific prefix potrivit. redirect-gateway def1 nu înlocuiește de obicei ruta implicită; adaugă două jumătăți, o rută pentru jumătatea inferioară a spațiului de adrese și una pentru cea superioară, astfel încât ruta implicită originală este păstrată pentru alte utilizări. Acele jumătăți sunt mai largi decât o singură adresă.

O rută pentru o adresă cu masca 255.255.255.255 este un /32, adică specificitatea maximă pe care o poate oferi IPv4. Când este evaluat un pachet pentru acea adresă, /32 se potrivește și câștigă indiferent de ruta instalată prima. Acesta este mecanismul din spatele excepției și funcționează la fel pe Linux, macOS și Windows atât timp cât ruta este într-adevăr prezentă.

Windows adaugă o a doua dimensiune. Când două rute sunt la fel de specifice, câștigă cea cu metrica mai mică, iar un adaptor VPN poate purta o metrică de interfață care schimbă rezultatul. Un /32 rămâne mai specific decât jumătățile, așa că excepția se menține de obicei, dar o rută veche dintr-o sesiune anterioară poate produce un rezultat confuz dacă este la fel de specifică.

Ce nu acoperă excepția

DNS este prima lacună. Clientul poate împinge setări interne ale resolverului, iar sistemul de operare le va folosi în continuare pentru interogări. O aplicație care rezolvă un nume înainte de conectare poate primi o adresă internă pentru un serviciu care ar trebui să meargă direct, sau o adresă externă care se rezolvă corect dar apoi se împiedică de următoarea lacună.

IPv6 este a doua. Directiva de rută gestionează doar IPv4. O destinație cu stivă dublă poate prefera IPv6, care urmează tunelul sau ruta implicită IPv6 a gazdei în funcție de politică, așa că excepția IPv4 nu intră niciodată în joc. Aveți nevoie de o rută IPv6 corespunzătoare sau de o decizie deliberată de a dezactiva IPv6 pentru acel client.

Sfera aplicațiilor este a treia. Regula se bazează pe destinație, așa că fiecare proces care se conectează la acea adresă folosește calea directă, fie că este cel la care v-ați gândit, fie că nu. Invers, un site web poate răspunde din mai multe adrese, așa că exceptarea unui /32 nu exceptă site-ul. Dacă cerința reală este rutarea per aplicație, tabelul de rute al clientului Community este instrumentul greșit.

Verificarea excepției fără a vă înșela singur

Începeți cu ruta instalată, nu cu un browser. Pe Linux, întrebați kernelul ce rută și ce salt următor va folosi pentru adresa concretă; pe Windows, citiți tabelul de rute pentru acel /32. Confirmați că gateway-ul este cel fizic, nu tunelul. Dacă intrarea lipsește, profilul nu a fost aplicat sau clientul nu avea privilegiul de a schimba rute.

Apoi testați două destinații. O cerere către adresa exceptată ar trebui să iasă prin interfața fizică, iar o cerere către o adresă internă de control ar trebui să folosească în continuare tunelul. Testarea doar a adresei exceptate nu dovedește nimic despre restul tunelului, iar testarea unui site public testează adresa către care a fost rezolvat acel site, care poate să nu fie cea din regulă.

În final, verificați controalele care pot trece peste rută. Un kill switch pe partea clientului sau o setare block-outside-dns din Windows poate interzice traficul direct, iar acest lucru apare ca o conexiune care eșuează deși ruta este corectă. Nu dezactivați acele controale pentru a face excepția să pară că funcționează; dacă politica interzice calea directă, excepția este o problemă de proiectare pentru proprietarul serviciului VPN.

Verificați din nou după reconectare sau schimbarea rețelei, deoarece gateway-ul dinaintea VPN-ului și calea disponibilă sunt proprietăți ale momentului, nu ale profilului.