Domainalapú VPN-útválasztás kontra IP-útvonalak: melyik illik?

Egy IP-útvonal egy címelőtaggal egyezik, és a kernel további kérdések nélkül alkalmazza. Egy domainalapú VPN-szabály egy névvel egyezik, ami azt jelenti, hogy valaminek a veremben el kell döntenie, milyen címeket jelent ez a név jelenleg, és naprakészen kell tartania ezt a döntést. Ezek különböző mechanizmusok, különböző hibaüzemmódokkal, és a szállítók ugyanazt a szót használják mindkettőre. A funkciólistákon való összehasonlításuk elvéti a lényeget; aszerint hasonlítsa össze őket, mi történik, amikor a válasz megváltozik.

A hasznos felosztás a feloldó szabály és a nem feloldó szabály között van.

Mihez illeszkedik valójában az egyes szabályok

Az előtagszabály az útválasztási táblázat célcímeihez illeszkedik. Semmi nem oldódik fel, semmi nem jár le, és az egyezés minden csomagra pontos. A domainszabály egy alkalmazás névre vonatkozó kéréséhez illeszkedik, amelyet RFC 1034 címkék fájaként határoz meg, nem címként. Egyes termékek egyszer feloldják a nevet, és az így kapott címeket útvonalként telepítik, ami a szabályt egy frissítési időzítővel ellátott IP-szabállyá teszi.

Tudja meg, melyikük van Önnél, mielőtt hibakeresésbe kezd, mert a hiba mindkét esetben teljesen másképp néz ki.

Hol lakik a domainszabály a veremben

Ha a termék helyi proxy segítségével valósítja meg a domainszabályokat, a forgalomnak el kell jutnia ehhez a proxyhoz, és a rendszerproxy-t figyelmen kívül hagyó alkalmazások teljesen megkerülik a szabályt. Ha nevek feloldásával és útvonalak hozzáadásával valósítja meg őket, a címek csak az utolsó frissítésig frissek. Ha ráakasztja magát a feloldóra, a DNS-viselkedés az útválasztási házirend részévé válik, és egy tartalék feloldó csendesen visszavonhatja azt.

A szállító modelljét olvassa, ne a beállítás címkéjét. Két kliens egy Split Tunnel nevű mezővel három különböző dolgot tehet.

Hasonlítsa össze, mi törik el

Három dolog törik el különbözőképpen. Címváltozás: egy CDN-hosztnév perceken belül más címkészletre oldódhat fel, így a másolt lista rosszul öregszik. Aldomain-hatókör: az example.com szabály lefedheti vagy nem fedheti le az api.example.com címet, és a dokumentáció általában egyértelmű ebben. Feloldási hiba: amikor a feloldó meghibásodik, a feloldó kliens visszaeshet a forgalom alagutazására vagy annak közvetlen küldésére.

Csak a második konfigurációs kérdés. A másik kettő tervezési kérdés arról, mennyit hajlandó tippelni a termék.

Amikor az előtag a jobb válasz

Egy stabil privát alhálózathoz az explicit előtag világosabb, gyorsabb és könnyebben auditálható. Túléli a feloldó kiesését is, mert semmit nem kell feloldani. Akkor nyúljon domainszabályhoz, ha a szolgáltatás hosztolt, ha a címek forognak, vagy ha valóban nem tudja felsorolni a célkészletet. Ne csak azért nyúljon hozzá, mert a hosztnév az, amit véletlenül ismer.

Egy kitalált statikus lista a legrosszabb mindkettőből: karbantartottnak látszik, és csendesen kihagyja a forgalmat azon a napon, amikor a szolgáltató hosztot ad hozzá.

Ellenőrizze friss kéréssel

Teszteljen hideg kéréssel egy normál újracsatlakozás után, mert egy gyorsítótárazott oldal soha nem érintheti a szabályt. Oldja fel a nevet, majd ellenőrizze, hová ment valójában a kapcsolat. dig +short app.example.com adja az aktuális címkészletet, és a kliens kapcsolatlistája megmondja, melyik interfész vitte a folyamot.

Ismételje meg a termék által dokumentált frissítési időköz után. Ha a címkészlet elcsúszik, és a szabály nem követi, megtalálta a valódi viselkedést.

Tartsa külön a feloldó házirendjét is. A domainszabály helyes névadatokat igényel, de önmagában nem dönti el, melyik feloldó válaszol a lekérdezésre.