VPN směrování podle domén versus IP trasy: které se hodí?
Název hostitele v poli pro rozdělený tunel není trasa. Porovnejte doménová pravidla a explicitní prefixy z hlediska obnovy, rozsahu subdomén a toho, co se stane, když se změní DNS.
IP trasa odpovídá prefixu adresy a jádro ji použije, aniž by se dál ptalo. Pravidlo VPN založené na doméně odpovídá názvu, což znamená, že něco v zásobníku musí rozhodnout, které adresy ten název právě teď znamená, a udržovat to rozhodnutí aktuální. To jsou různé mechanismy s různými režimy selhání a výrobci používají stejné slovo pro oba. Porovnávat je v seznamech funkcí míjí podstatu; porovnávejte je podle toho, co se stane, když se odpověď změní.
Užitečné rozdělení je mezi pravidlem, které překládá, a pravidlem, které ne.
S čím každé pravidlo skutečně odpovídá
Pravidlo prefixu odpovídá cílovým adresám ve směrovací tabulce. Nic se nepřekládá, nic nevyprší a shoda je přesná pro každý paket. Pravidlo domény odpovídá požadavku aplikace na název, který RFC 1034 definuje jako strom popisků, nikoli jako adresu. Některé produkty přeloží název jednou a výsledné adresy nainstalují jako trasy, čímž se pravidlo stane IP pravidlem s připojeným časovačem obnovy.
Než začnete ladit, zjistěte, který z těch dvou máte, protože selhání vypadá v každém případě úplně jinak.
Kde pravidlo domény v zásobníku žije
Pokud produkt implementuje doménová pravidla přes místní proxy, provoz se musí dostat k této proxy a aplikace, které ignorují systémovou proxy, pravidlo úplně obejdou. Pokud je implementuje překladem názvů a přidáváním tras, jsou adresy čerstvé jen do poslední obnovy. Pokud se chytá překladače, stává se chování DNS součástí směrovací politiky a záložní překladač to může tiše zrušit.
Čtěte model výrobce, ne popisek nastavení. Dva klienti s políčkem jménem Split Tunnel mohou dělat tři různé věci.
Porovnejte, co se rozbije
Tři věci se rozbíjejí různě. Změna adres: název hostitele CDN se může přeložit na jinou sadu adres během několika minut, takže zkopírovaný seznam rychle stárne. Rozsah subdomén: pravidlo pro example.com může a nemusí pokrývat api.example.com a dokumentace obvykle výslovně uvádí, který případ platí. Selhání překladu: když překladač selže, klient, který překládá, se může vrátit k tunelování provozu nebo k jeho přímému odesílání.
Jen druhá je otázka konfigurace. Zbývající dvě jsou otázky návrhu, nakolik je produkt ochoten hádat.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
Kdy je prefix lepší odpovědí
Pro stabilní privátní podsíť je explicitní prefix jasnější, rychlejší a snáze auditovatelný. Přežije i výpadek překladače, protože se nic nemusí překládat. Pravidlo domény použijte, když je služba hostovaná, když se adresy točí nebo když skutečně nedokážete vyjmenovat sadu cílů. Nesahejte po něm jen proto, že název hostitele je věc, kterou náhodou znáte.
Odhadovaný statický seznam je nejhorší z obojího: vypadá udržovaně a tiše mine provoz v den, kdy poskytovatel přidá hostitele.
Ověřte čerstvým požadavkem
Otestujte studeným požadavkem po běžném opětovném připojení, protože stránka z mezipaměti se pravidla možná nikdy nedotkne. Přeložte název a potom zkontrolujte, kam spojení skutečně šlo. dig +short app.example.com dává aktuální sadu adres a seznam spojení klienta vám řekne, které rozhraní tok neslo.
Opakujte po intervalu obnovy, který produkt dokumentuje. Pokud se sada adres posune a pravidlo ji nenásleduje, našli jste skutečné chování.
Politiku překladače držte také odděleně. Pravidlo domény potřebuje správná data o názvech, ale samo o sobě nerozhoduje, který překladač na dotaz odpoví.