Domein-basearre VPN-routing tsjin IP-rûtes: hokker past?
In hostnamme yn in split-tunnel-fak is gjin rûte. Ferlykje domeinregels en eksplisite prefiksen op ferfarskjen, subdomeinberik en wat der bart as DNS feroaret.
In IP-rûte komt oerien mei in adresprefiks, en de kernel past dy ta sûnder fierdere fragen. In domein-basearre VPN-regel komt oerien mei in namme, wat betsjut dat eat yn 'e stapel beslute moat hokker adressen dy namme op dit stuit betsjut en dat beslút aktueel hâlde moat. Dat binne ferskate meganismen mei ferskate flatermodus, en leveransiers brûke itselde wurd foar beide. Se ferlykje op funksjelisten mist it punt; ferlykje se op wat der bart as it antwurd feroaret.
De nuttige skieding is tusken in regel dy't oplost en in regel dy't dat net docht.
Wêr't elke regel eins mei oerienkomt
In prefiksregel komt oerien mei bestimmingsadressen yn in rûtingstabel. Neat wurdt oplost, neat ferrint, en de oerienkomst is krekt foar elk pakket. In domeinregel komt oerien mei in oanfraach fan in applikaasje om in namme, dy't RFC 1034 definiearret as in beam fan labels ynstee fan in adres. Guon produkten lossen de namme ien kear op en ynstallearje de resultearjende adressen as rûtes, wat de regel in IP-regel makket mei in ferfarskjenstiimer deroan fêst.
Wit hokker fan de twa jo hawwe foardat jo it debugge, want de flater sjocht der yn elk gefal hiel oars út.
Wêr't de domeinregel yn 'e stapel wennet
As it produkt domeinregels ymplemintearret fia in lokale proxy, moat ferkear dy proxy berikke, en applikaasjes dy't de systeemproxy negearje, geane folslein by de regel lâns. As it se ymplemintearret troch nammen op te lossen en rûtes ta te foegjen, binne de adressen mar sa farsk as de lêste ferfarsking. As it de oplosser heakket, wurdt DNS-gedrach diel fan it rûtingsbelied, en in fallback-oplosser kin dat stil weromdraaie.
Lês it model fan de leveransier ynstee fan it label fan de ynstelling. Twa kliïnten mei in fak mei de namme Split Tunnel kinne trije ferskate dingen dwaan.
Ferlykje wat der brekt
Trije dingen brekke oars. Adresferrin: in CDN-hostnamme kin binnen minuten nei in oare adresset oplosse, dus in kopiaarje list ferrint min. Subdomeinberik: in regel foar example.com kin api.example.com wol of net dekke, en de dokumintaasje is meastentiids dúdlik oer hokker. Oplosflater: as de oplosser falt, kin in oplossende klant weromfalle op it tunneljen fan it ferkear of op it direkt ferstjoeren.
Allinnich de twadde is in konfiguraasjefraach. De oare beide binne ûntwerpfragen oer hoefolle it produkt bereid is te rieden.
| 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 |
Wannear't it prefiks it bettere antwurd is
Foar in stabyl privee subnet is in eksplisyt prefiks dúdliker, flugger en makliker te auditearjen. It oerlibbet ek in oplosserstoring, om't neat oplost hoecht te wurden. Griip nei in domeinregel as de tsjinst host wurdt, as adressen draaie of as jo echt de bestimmingsset net opfine kinne. Griip der net nei allinnich om't de hostnamme it ding is dat jo tafallich witte.
In rieden statyske list is it minste fan beide: it liket ûnderhâlden en mist stil ferkear op 'e dei dat de oanbieder in host tafoeget.
Ferifiearje mei in farsk fersyk
Test mei in kâld fersyk nei in normale werferbining, om't in cache-side de regel miskien nea rekket. Los de namme op en kontrolearje dan wêr't de ferbining eins hinne gie. dig +short app.example.com jout de hjoeddeiske adresset, en de ferbiningslist fan 'e klant fertelt jo hokker ynterface de stream droech.
Werhelje nei it ferfarskjenstiidperk dat it produkt dokumintearret. As de adresset ferskoot en de regel folget net, hawwe jo it echte gedrach fûn.
Hâld it oplosserbelied ek apart. In domeinregel hat kloppe nammedata nedich, mar beslút sels net hokker oplosser it fraach beantwurdet.