Dokumintaasje fan split-tunnel hat in DNS-regel njonken elke rûte nedich
In rûte beslút op adres, in resolver beslút op namme. Dokumintearje beide selektors per stream, elk mei ien test, oars falt de notysje as DNS ferskoot.
In notysje oer split-tunnel dy't seit "kantoarferkear giet troch de VPN" hat ien beslút dokumintearre en trije oare ymplisearre. Op pakketnivo kiest in routingtabel in ynterface op bestemmingsadres; op nammenivo kiest in resolver in server op fraach, en de twa karren wurde ûnôfhinklik makke. Dêrom kin in korrekt dokumintearre foarheaksel noch altyd in masine produsearje dy't in ynterne namme nei in iepenbier adres oplost, of neat oplost wylst de rûte perfekt liket.
Twa selektors, ien ferbiningspoging
As in applikaasje ferbynt mei files.corp.example, dan barre der twa syktochten foardat der in pakket bestiet. De resolver beslút hokker server de fraach krijt, mei sykdomeinen, routingdomeinen per keppeling of in eksplisite profylregel. De routingtabel beslút dan wêr't it resultearjende adres hinne giet, mei de langste foarheakselfoech by de bestemming.
Neat ferbynt dy twa besluten. In privee sône kin antwurdzje mei 10.20.4.11 wylst de routingtabel 10.20.0.0/16 de tunnel yn stjoert, en de ferbining wurket. Draai ien fan beide om en it falt op in manier dy't op it oare liket: goed DNS-belied plus in ûntbrekkende rûte jout in oploste namme en in tiidferrin, wylst in korrekte rûte plus in iepenbiere resolver in adres jout dat skjin nei it ferkearde plak rûtelet.
Split-horizon-DNS makket dit skerper. Deselde namme kin in privee adres fan de ynterne resolver en in iepenbier adres fan de internetrjochte weromjaan, dus in notysje dy't allinnich it foarheaksel fêstleit, kin net foarsizze hokker adres de klant eins brûkt. Skriuw it resolverpaad op, oars is it adres in gok.
Wat in notysje allinnich oer de rûte weilitten
In opname allinnich oer de rûte is ûnbrûkber foar de meast foarkommende split-tunnel-flater: nammen. De brûker meldt dat it intranet net laden, de tunnel is omheech en it foarheaksel is oanwêzich. Wa't it ticket oannimt, hat gjin opname fan hokker resolver antwurdzje moatten hie, gjin manier om in ferkeard syk-efterheaksel fan in blokkearre server te ûnderskieden, en gjin basisline om mei te fergelykjen.
De twadde weilitting is de útsûnderingslist. In split-tunnel-ûntwerp wurdt likefolle bepaald troch wat bûten de tunnel bliuwt as troch wat der yn komt, en de útsletten berikken binne meastentiids dejinge dy't it earst brekke, om't in mear spesifike lokale rûte of in filter oan klantkant de bedoeling oerhearskje kin sûnder it profyl oan te reitsjen.
De tredde is de fiere kant fan de tunnel. In klantrûte set it pakket allinnich op 'e tried; de gateway moat it noch trochstjoere en in weromwei hawwe. De hantlieding foar trochstjoeren fan strongSwan is in herinnering dat trochstjoer- en firewallregels op 'e gateway diel fan 'e funksje binne, net diel fan 'e lieding dy't jo oannimme kinne.
De fjilden dy't de notysje útfierber meitsje
Ien rige per stream, en in stream is in bestemming plus in namme plus in eigner. Dit binne de fjilden dy't it kontakt mei in echte ynsidint oerlibje:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
De rige "wêr't it wennet" is dejinge dy't minsken oerslaan. In foarheaksel dat troch de server drukt wurdt, in rûte dy't troch in klantprofyl tafoege wurdt en in rûte dy't yn in shell typt wurdt, ferskille yn wa't se feroarje kin en of se in werferbining oerlibje. Sûnder dat fjild kin de folgjende yngenieur net sizze hokker fan 'e trije er sjocht.
Ien test per regel, net ien per tunnel
Elke rige hat twa ûnskealike kontrôles nedich: ien dy't de rûte oefent en ien dy't de namme oefent. Foar de rûte, freegje om eat dat de tunnel oerstekke moat en befêstigje it paad ynstee fan 'e berikberens, bygelyks tracert -d 10.20.4.11 op Windows of ip route get 10.20.4.11 op Linux. Foar de namme, freegje de privee namme op en registrearje hokker server antwurde, mei resolvectl query files.corp.example of dig files.corp.example tsjin de resolver dy't de notysje neamt.
Foegje ek in negative ferwachting ta: wat der barre moat as de tunnel del is. In útsletten applikaasje op in Android- of iOS-apparaat mei blokkearje-sûnder-VPN ynskeakele hat miskien hielendal gjin ferbining, en in desktopklant kin deselde app wurkje litte wylst de tunnel wer ferbynt. It fêstlizzen fan it bedoelde antwurd makket "de VPN bruts myn app" ta in kontrolearbere útspraak.
Hâld de opname by de konfiguraasje
Bewarje de notysje njonken it profyl dat it beskriuwt en ferzje it mei dat profyl. In dokumint yn in wiki dat nimmen bywurket is in geroft; in tabel yn itselde bewarplak as de drukte rûtes en it resolverbelied kin yn deselde feroaring besjoen wurde.
As der wat brekt, fergelykje dan de tapaste rûte en de effektive resolver mei de opname foardat jo noch in útsûndering tafoegje. Twa fan 'e trije foarkommende oarsaken — in âlde nammerûmteregel en in help-proses bûten it app-belied — lykje krekt op in VPN-flater en binne ûnsichtber as de notysje allinnich foarheaksels listet.
Foardat jo de notysje klear neame, befêstigje dat it dizze dingen skriftlik beantwurdet: hokker foarheaksel, foar hokker adresfamylje; hokker privee nammerûmte, beantwurde troch hokker resolver; hokker nammen bewust iepenbier bliuwe; wêr't elke regel konfigurearre is en wa't it besit; en it iene kommando dat de rûte bewist en it iene dat de namme bewist. As ien fan dy mist, sil it folgjende ynsidint fanôf nul diagnostisearre wurde.