Miért nem működhet egy wildcard az OpenVPN route-direktívájában

a route címelőtagokat telepít, ezért a hosztnév-mintának nincs mihez illeszkednie. Használjon előtagot a hálózatokhoz, és proxyt vagy PAC-fájlt, amikor a tartományoknak kell dönteniük.

A szándék ésszerű: egy vállalati tartomány minden forgalmát a tunelen át küldeni, a többit pedig békén hagyni. A szerkesztett direktíva route-okat telepít, és a route-nak nincs fogalma hosztnévről, amihez illeszkedhetne. Minden kísérlet, hogy wildcardot írjunk bele, vagy elemzési hibát ad, vagy – ami rosszabb – olyan route-ot, amely ma véletlenül működik, mert a név egyetlen címre oldódott fel. Két különböző mechanizmust kérünk arra, hogy egymás munkáját végezze.

Mit telepít egy route, és mit nem olvas soha

Egy route-bejegyzés azt mondja, hogy egy cél-előtag egy interfészen keresztül elérhető. A kernel a csomagokat ezekhez az előtagokhoz illeszti, így az egyetlen érintett azonosító a cím és a maszk. Hosztnév soha nem jelenik meg a továbbítási döntésben, ezért ott minta nem illeszthető.

OpenVPN bizonyos route-paraméterekben elfogadhat feloldható nevet, és ez a tolerancia a zavar forrása. A nevet a konfiguráció alkalmazásakor oldja fel, ami egy vagy több címet hoz létre, amelyek közönséges route-okká válnak. Utána a név teljesen eltűnik a képből.

Tehát a névből épített route pillanatkép, nem szabály. Azt fedi le, amivé a név a tunel indulásának pillanatában feloldódott, és pontosan ez az a viselkedés, amit egy változó hosztcsaládnál nem szeretne. Egy rekord, amely holnap elmozdul, a route-ot a tegnapra mutatva hagyja.

Amikor a cél valóban egy előtag

Ha a cél egy ismert magánhálózat, írja le az előtagot. A dokumentációs térből vett példában egyetlen hoszt és egy alhálózat így néz ki:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Mindkét bejegyzés címeket és maszkokat nevez meg, és mindkettő túléli a DNS-változásokat, mert semmi bennük nem függ egy névtől. Ez az egész előny: a route a topológiáról szóló állítás, nem egy egyszer megtörtént keresésről.

Ne vezessen le nagy előtagot egyetlen DNS-válaszból. Egy hosztnév, amely egyetlen címre oldódik fel, semmit nem mond a mögötte lévő hálózat méretéről, és a kitalált előtag az, ahogy egy tunel végül olyan forgalmat fog el, amelyet senki nem szándékozott rajta átküldeni. Kérdezze meg a hálózat tulajdonosát a tényleges előtagról, ahelyett hogy egy keresésből következtetne rá.

Amikor a munkaegység egy hosztnév

A tartomány szerinti kiválasztáshoz kell valami, ami olvassa a tartományt, azaz egy alkalmazási rétegbeli komponens. A szokásos válasz egy HTTP-proxy, amely a tunel túlsó oldalán él, és a kliens választja ki, mely kéréseket küldi neki.

Egy proxy-konfigurációs fájl kifejezheti ezt a választást. Az alábbi szemléltető szabályok egy tartományt és annak aldomainjeit proxyra, minden mást pedig közvetlenül küldenek:

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

A pontos név összehasonlítása magát a tartományt fedi le, a végződés összehasonlítása pedig a gyermekeit, anélkül hogy olyan névre illeszkedne, amely csak hasonló karakterekre végződik. Mindkettő szükséges, és az egyik kihagyása olyan szabályt ad, amely helyesnek látszik, és kihagyja a csúcsot vagy egy imposztort.

Ezek a szabályok proxyt választanak; nem hoznak létre egyet, és nem változtatnak meg semmilyen operációs rendszerbeli route-ot. A proxy címének továbbra is saját útra van szüksége a tunelen át, és a közvetlenként megjelölt kérések továbbra is azt az útválasztási szabályzatot követik, amely a gépen már van.

Mit nem fed le a proxy opció

A böngésző proxy-konfigurációját figyelmen kívül hagyó programokra ebből semmi nem hat. A parancssori eszközök, a frissítők és a saját hálózati veremmel rendelkező alkalmazások a route-táblát veszik, nem a PAC-fájlt, ezért ezekben az esetekben támogatott alkalmazásonkénti mechanizmusra vagy más tervezésre van szükség. Leltározza fel az igazán fontos klienseket, mielőtt megígéri, hogy a böngészőszabály lefedi a munkafolyamatot.

A közvetlen visszatérés sem menekülőút. Ha a gép útválasztási szabályzata már mindent a tunelbe küld, a közvetlenként megjelölt kérés azon belül marad, mert a proxy választása és a route-tábla különböző döntések, amelyeket különböző rétegeken hoznak.

A névfeloldás egy harmadik, külön kérdés. Annak kiválasztása, mely kérések mennek proxyra, semmit nem mond arról, melyik feloldó válaszol rájuk, és ha a kettőt egyetlen beállításnak tekintjük, olyan szivárgások keletkeznek, amelyek láthatatlanok, amíg valaki kívülről nem tesztel. Döntse el, hol válaszolják meg az egyes lekérdezéseket, és írja le ezt a döntést a proxy szabálya mellé. Egy feloldó, amely azért változik meg, mert a tunel feljött, csendesen elmozdítja a választ.

Mindkét utat tesztelni, nem csak a boldogot

Teszteljen egy hosztnevet, amelynek illeszkednie kellene, egyet, amelynek nem, és a tartomány csúcsát, mivel a csúcs az az eset, amelyet a csak végződésre épülő szabály a leggyakrabban kihagy. Ezután erősítse meg, melyik utat tette meg az egyes kérések valójában, ahelyett hogy abból következtetne, betöltődött-e az oldal.

Végül tesztelje a hibaágat. Az elérhetetlen proxynek úgy kell meghibásodnia, ahogy előre eldöntötte, nem pedig csendesen visszaesnie egy közvetlen kapcsolatra. A hálózati beállítások referenciája pontosan dokumentálja a route-paramétereket; ennek a tervezésnek a tartományi fele teljesen azon kívül él.

Kapcsolódó cikkek