pull-filter din OpenVPN se potrivește cu mai mult decât ruta dorită
pull-filter compară textul tău ca prefix cu opțiunile împinse, așa că route prinde și route-gateway și route-ipv6. Verifică verbele, apoi rutele.
Adaugi o linie pentru a păstra ruta implicită locală, iar după aceea tunelul nu mai ajunge la serverul DNS intern. Linia era pull-filter ignore "route", ceea ce nu înseamnă „ignoră această rută”. Înseamnă „aruncă fiecare opțiune împinsă al cărei text începe cu acele cinci litere”, iar pe un server normal asta include route-gateway, route-metric și route-ipv6 împreună cu rutele înseși. Lista de verificare de mai jos este ceea ce parcurg înainte de a atinge un profil pe care trebuie să îl folosească altcineva.
Filtrul se aplică doar opțiunilor împinse
pull-filter acționează doar asupra liniilor de opțiuni pe care serverul le trimite după stabilirea tunelului, și asupra nimic altceva. Opțiunile scrise în fișierul tău local nu sunt afectate, la fel nici traficul aplicațiilor. Dacă sperai să împiedici un proces să folosească tunelul, acesta este complet instrumentul greșit și nicio combinație de filtre nu va face asta.
Acel domeniu este util, pentru că înseamnă că poți lăsa configurația serverului în pace și totuși să refuzi o parte din ea local. Este și o limitare care merită notată în tichet: un filtru schimbă ce acceptă acest client, nu ce oferă serverul. Nu are niciun efect asupra altor utilizatori ai aceluiași profil. Nu supraviețuiește nici trecerii la alt client care nu implementează opțiunea, ceea ce merită știut înainte de a construi un flux de lucru pe ea.
Confirmă ce trimite de fapt serverul înainte de a scrie modelul. La verbositate ridicată clientul tipărește șirul de opțiuni împinse pe care l-a primit, iar acesta este singura sursă onestă pentru textul exact cu care compari:
sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn
Citește linia împinsă ca o listă de opțiuni separate prin virgule și observă că numele opțiunilor și argumentele lor sunt separate prin spații. Textul filtrului tău este comparat cu acel flux, de aceea spațiile contează atât de mult în pasul următor.
Potrivirea este un prefix, deci spațiile decid totul
Comparația este un prefix de șir, nu un nume de opțiune analizat. De aceea "route" se potrivește cu route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 și route-metric 100. Un spațiu final îl restrânge la familia la care probabil te refereai, iar prefixul complet îl restrânge și mai mult la o destinație anume.
| Filter text | What it actually matches | Typical outcome |
|---|---|---|
"route" | Every option beginning with those letters | Routes, gateway, metric and IPv6 routes all dropped |
"route " | Route entries only, not the hyphenated siblings | The routes go, the rest survives |
"route 10.60." | A single destination range | The narrowest rule, and the easiest to audit |
"dhcp-option DNS" | Pushed DNS settings | Resolver stays local, internal names stop resolving |
Ultimul rând este cel care prinde oamenii în timpul lucrului cu tunel divizat. Păstrarea propriului resolver este o alegere legitimă și înseamnă că fiecare nume intern depinde acum de un resolver care nu vede zona privată. Este o consecință acceptată intenționat, nu un efect secundar descoperit în producție.
Potrivirea pe prefix înseamnă și că o regulă se poate extinde mai târziu în tăcere. Când serverul adaugă o opțiune nouă care începe cu textul tău, filtrul tău începe să se aplice asupra ei fără ca cineva să editeze profilul. Acesta este modul de eșec împotriva căruia trebuie proiectat, iar atenuarea este să potrivești cât mai mult din opțiune, nu cât mai puțin.
Trei verbe cu trei rezultate diferite
accept, ignore și reject nu sunt trei grafii ale aceleiași idei. Ele diferă prin ce face clientul cu o potrivire și prin dacă află cineva.
ignore aruncă în tăcere opțiunea potrivită, ceea ce vrei pentru o setare pe care ai înlocuit-o deliberat. reject o aruncă și face clientul să se plângă, ceea ce vrei atunci când absența ei trebuie să fie vizibilă într-un jurnal în loc să fie descoperită mai târziu. accept este forma pozitivă, folosită când construiești o listă de permisiuni în loc să elimini opțiuni individuale.
Orice verb ai folosi, filtrele se aplică în ordinea în care apar, așa că două reguli suprapuse produc un rezultat dependent de ordine și foarte greu de revizuit. Ține o regulă pe intenție și pune textul cel mai specific în fiecare. Dacă ai nevoie de o listă de permisiuni, preferă câteva reguli accept în locul unei grămezi de reguli ignore care însumează același lucru. Atunci recenzenții pot citi fișierul de sus în jos și pot prezice rezultatul, iar acesta este singurul test care scalează.
Verifică ruta și resolverul aplicate, nu profilul
Un filtru care arată corect în fișier te poate lăsa totuși cu un tunel care nu rutează nimic util. Verifică efectul pe sistemul care rulează, unde opțiunile împinse au fost deja aplicate sau aruncate:
ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/
Primele două linii îți spun dacă a sosit ruta implicită împinsă și câte intrări statice au supraviețuit. Interogarea resolverului arată ce server folosește de fapt interfața tunelului, și de obicei acolo apare o surpriză DNS. Ultima linie răspunde la singura întrebare care contează pentru un utilizator.
Testează ambele direcții cât timp ești acolo. O regulă care îți menține internetul local funcțional dar rupe în tăcere rezolvarea numelor interne trece de o verificare superficială și eșuează la prima sarcină reală, așa că include un resurs intern și un site public în același test.
Notează excepția și proprietarul ei
Un filtru este o excepție de la proiectarea operatorului, așa că scrie-l cu un motiv și un punct de revizuire. „Ignoră rutele împinse pentru a păstra implicitul local” este revizuibil; o linie goală într-un profil nu este, iar următoarea persoană o va șterge sau o va extinde ghicind.
Și versiunea contează aici. Comportamentul de potrivire și sintaxa exactă acceptată au fost rafinate în OpenVPN 2.4, 2.5 și 2.6, așa că verifică modelul în manualul versiunii pe care o distribui și nu într-o postare de forum despre o versiune mai veche. Manualul OpenVPN 2.6 documentează opțiunea și regula ei de potrivire.
În final, conveniește excepția cu cel care administrează serverul. Un filtru pe partea clientului care contrazice o politică deliberată a serverului este un incident de suport care așteaptă următorul audit, și este mult mai ieftin de rezolvat înainte ca profilul să fie livrat decât după ce cineva observă că lipsesc rutele.