Proč zástupný znak v direktivě route OpenVPN nemůže fungovat

trasa instaluje prefixy adres, takže vzor názvu hostitele nemá s čím porovnávat. Pro sítě použijte prefix a tam, kde mají rozhodovat domény, proxy nebo soubor PAC.

Záměr je rozumný: poslat vše pro jednu firemní doménu tunelem a zbytek nechat být. Upravovaná direktiva instaluje trasy a trasa nemá žádný pojem názvu hostitele, se kterým by se dalo porovnávat. Každý pokus zapsat do ní zástupný znak skončí buď chybou parsování, nebo, což je horší, trasou, která dnes funguje náhodou, protože se název přeložil na jednu adresu. Dva různé mechanismy jsou žádány, aby dělaly práci jeden druhému.

Co trasa instaluje a co nikdy nečte

Záznam trasy říká, že cílový prefix je dostupný přes rozhraní. Jádro porovnává pakety s těmito prefixy, takže jediné zúčastněné identifikátory jsou adresy a masky. Název hostitele se v rozhodnutí o předávání nikdy neobjeví, a proto tam vzor nelze porovnat.

OpenVPN dokáže v některých parametrech trasy přijmout přeložitelný název a tato tolerance je zdrojem zmatku. Název se přeloží při aplikaci konfigurace a vznikne jedna nebo více adres, které se stanou běžnými trasami. Poté název z obrazu úplně zmizí.

Trasa postavená z názvu je tedy snímek, ne pravidlo. Pokrývá to, na co se název přeložil v okamžiku spuštění tunelu, což je přesně chování, které u měnící se rodiny hostitelů nechcete. Záznam, který se zítra přesune, nechá trasu ukazovat na včerejšek.

Když je cílem skutečně prefix

Pokud je cílem známá privátní síť, napište prefix. Pro příklad z dokumentačního prostoru vypadá jeden hostitel a jedna podsíť takto:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Oba záznamy uvádějí adresy a masky a oba přežijí změny DNS, protože nic v nich nezávisí na názvu. V tom je celá výhoda: trasa je tvrzení o topologii, ne o vyhledání, které proběhlo jednou.

Neodvozujte velký prefix z jediné odpovědi DNS. Jeden název hostitele přeložený na jednu adresu vám nic neříká o velikosti sítě za ním a odhadnutý prefix je způsob, jak tunel začne zachytávat provoz, který přes něj nikdo posílat nechtěl. Zeptejte se vlastníka sítě na skutečný prefix, místo abyste ho odvozovali z vyhledání.

Když je jednotkou práce název hostitele

Výběr podle domény vyžaduje něco, co doménu čte, tedy komponentu aplikační vrstvy. Obvyklou odpovědí je HTTP proxy, která žije na druhé straně tunelu, a klient volí, které požadavky jí pošle.

Konfigurační soubor proxy může tento výběr vyjádřit. Ilustrativní pravidla níže posílají jednu doménu a její subdomény na proxy a vše ostatní přímo:

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";
}

Porovnání přesného názvu pokrývá samotnou doménu a porovnání přípony pokrývá její potomky, aniž by odpovídalo názvu, který jen končí podobnými znaky. Obě jsou potřeba a vynechání jednoho vytvoří pravidlo, které vypadá správně a přeskakuje vrchol nebo podvodníka.

Tato pravidla vybírají proxy; nevytvářejí ji a nemění žádnou trasu operačního systému. Adresa proxy stále potřebuje vlastní cestu tunelem a požadavky označené jako přímé stále následují politiku směrování, kterou stroj už má.

Co volba proxy nepokrývá

Programy, které ignorují konfiguraci proxy v prohlížeči, tím nebudou vůbec ovlivněny. Nástroje příkazového řádku, aktualizátory a aplikace s vlastním síťovým zásobníkem berou směrovací tabulku, ne soubor PAC, takže tyto případy potřebují podporovaný mechanismus pro jednotlivou aplikaci nebo jiný návrh. Než slíbíte, že pravidlo prohlížeče pokrývá pracovní postup, zjistěte, kteří klienti jsou důležití.

Vrátit se přímo také není úniková cesta. Pokud politika směrování stroje už posílá vše do tunelu, požadavek označený jako přímý zůstane uvnitř, protože volba proxy a směrovací tabulka jsou různá rozhodnutí učiněná v různých vrstvách.

Překlad názvů je třetí samostatná otázka. Volba, které požadavky jdou na proxy, nic neříká o tom, který resolver na ně odpovídá, a zacházení s oběma jako s jedním nastavením vytváří úniky, které jsou neviditelné, dokud to někdo neotestuje zvenčí. Rozhodněte, kde se každý dotaz zodpovídá, a toto rozhodnutí zapište vedle pravidla proxy. Resolver, který se změní proto, že se tunel zvedl, odpověď tiše přesune.

Testovat obě cesty, ne jen tu šťastnou

Otestujte název hostitele, který by měl odpovídat, název hostitele, který by neměl, a vrchol domény, protože vrchol je případ, který pravidlo jen s příponou nejčastěji mine. Potom potvrďte, kterou cestou každý požadavek skutečně šel, místo abyste to odvozovali z toho, zda se stránka načetla.

Nakonec otestujte větev selhání. Proxy, která je nedostupná, by měla selhat způsobem, který jste předem rozhodli, místo aby tiše přešla na přímé připojení. Reference síťových voleb dokumentuje parametry trasy přesně; doménová polovina tohoto návrhu žije zcela mimo ni.

Související články