De ce un wildcard într-o directivă route OpenVPN nu poate funcționa

ruta instalează prefixe de adresă, așa că un model de nume de gazdă nu are cu ce să se potrivească. Folosiți un prefix pentru rețele și un proxy sau fișier PAC atunci când domeniile trebuie să decidă.

Intenția este rezonabilă: trimite totul pentru un domeniu al companiei prin tunel și lasă restul în pace. Directiva care este editată instalează rute, iar o rută nu are niciun concept de nume de gazdă cu care să se potrivească. Fiecare încercare de a scrie un wildcard în ea produce fie o eroare de analiză, fie, mai rău, o rută care astăzi funcționează din întâmplare pentru că numele s-a rezolvat la o singură adresă. Se cere două mecanisme diferite să facă munca unul altuia.

Ce instalează o rută și ce nu citește niciodată

O intrare de rută spune că un prefix de destinație este accesibil printr-o interfață. Kernelul potrivește pachetele cu acele prefixe, deci singurii identificatori implicați sunt adrese și măști. Un nume de gazdă nu apare niciodată în decizia de redirecționare, și de aceea un model nu poate fi potrivit acolo.

OpenVPN poate accepta un nume rezolvabil în unii parametri de rută, iar această toleranță este o sursă de confuzie. Numele este rezolvat în timpul aplicării configurației, producând una sau mai multe adrese care devin rute obișnuite. După aceea, numele dispare complet din imagine.

Deci o rută construită din nume este o imagine instantanee, nu o regulă. Acoperă ceea ce acel nume a rezolvat în momentul în care tunelul a pornit, iar acesta este exact comportamentul pe care nu îl doriți pentru o familie de gazde care se schimbă. O înregistrare care se mută mâine lasă ruta arătând spre ieri.

Când destinația este într-adevăr un prefix

Dacă ținta este o rețea privată cunoscută, scrieți prefixul. Pentru un exemplu din spațiul de documentare, o singură gazdă și o subrețea arată astfel:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Ambele intrări numesc adrese și măști, și ambele supraviețuiesc modificărilor DNS pentru că nimic din ele nu depinde de un nume. Acesta este tot avantajul: ruta este o afirmație despre topologie, nu despre o căutare care a avut loc o dată.

Nu extrapolați un prefix mare dintr-un singur răspuns DNS. Un singur nume de gazdă care se rezolvă la o adresă nu vă spune nimic despre dimensiunea rețelei din spate, iar un prefix ghicit este modul în care un tunel ajunge să capteze trafic pe care nimeni nu intenționa să îl trimită prin el. Întrebați proprietarul rețelei despre prefixul real, în loc să îl deduceți dintr-o căutare.

Când unitatea de lucru este un nume de gazdă

Selectarea după domeniu necesită ceva care citește domeniul, adică o componentă de nivel aplicație. Răspunsul obișnuit este un proxy HTTP care se află de cealaltă parte a tunelului, clientul alegând ce cereri să îi trimită.

Un fișier de configurare al proxy-ului poate exprima această alegere. Regulile ilustrative de mai jos trimit un domeniu și subdomeniile lui către un proxy, iar restul direct:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

Comparația numelui exact acoperă domeniul în sine, iar comparația de sufix acoperă copiii lui fără a se potrivi cu un nume care doar se termină în caractere similare. Ambele sunt necesare, iar omiterea uneia produce o regulă care pare corectă și sare peste vârf sau peste un impostor.

Aceste reguli aleg un proxy; nu creează unul și nu schimbă nicio rută a sistemului de operare. Adresa proxy-ului are în continuare nevoie de propria cale prin tunel, iar cererile marcate ca directe urmează în continuare politica de rutare pe care mașina o are deja.

Ce nu acoperă opțiunea de proxy

Programele care ignoră configurația de proxy a browserului nu vor fi afectate de nimic din toate acestea. Instrumentele din linia de comandă, actualizatoarele și aplicațiile cu propriul stivă de rețea iau tabelul de rute, nu fișierul PAC, așa că acele cazuri au nevoie de un mecanism pentru fiecare aplicație acceptat sau de un alt design. Inventariați clienții care contează înainte de a promite că regula browserului acoperă fluxul de lucru.

Întoarcerea directă nu este nici ea o cale de scăpare. Dacă politica de rutare a mașinii trimite deja totul în tunel, o cerere marcată ca directă rămâne înăuntru, pentru că alegerea proxy-ului și tabelul de rute sunt decizii diferite luate la niveluri diferite.

Rezolvarea numelor este o a treia întrebare separată. Alegerea cererilor care merg la un proxy nu spune nimic despre ce resolver le răspunde, iar tratarea celor două ca o singură setare produce scurgeri care sunt invizibile până când cineva testează din exterior. Decideți unde este răspunsă fiecare interogare și scrieți această decizie lângă regula de proxy. Un resolver care se schimbă pentru că tunelul a urcat va muta răspunsul în liniște.

Testarea ambelor căi, nu doar a celei fericite

Testați un nume de gazdă care ar trebui să se potrivească, un nume de gazdă care nu ar trebui, și vârful domeniului, deoarece vârful este cazul cel mai des omis de o regulă doar cu sufix. Apoi confirmați ce cale a luat de fapt fiecare cerere, în loc să deduceți din faptul că pagina s-a încărcat.

În final, testați ramura de eșec. Un proxy care nu poate fi atins ar trebui să eșueze într-un mod pe care l-ați decis dinainte, în loc să revină în liniște la o conexiune directă. Referința pentru opțiunile de rețea documentează precis parametrii de rută; jumătatea de domeniu a acestui design trăiește complet în afara ei.

Articole similare