Waarom jou split-tunnel-reël opgehou het om by 'n diens te pas
Die reël pen 'n voorvoegsel vas en die diens het geskuif. Lees die bestemming wat die app werklik gebruik en herstel dan die meganisme eerder as om die uitsondering te verbreed.
Split tunneling misluk gewoonlik op een van twee maniere. Of verkeer wat binne die tonnel moet wees, gaan om dit, of verkeer wat buite moet bly, word ingetrek. Die verouderde-reël-mislukking is die eerste soort, en dit is die verwarrendste, want die reël word presies soos geskryf toegepas. Wat verander het, is die bestemming: die diens antwoord nou op 'n adres wat die reël nooit genoem het nie, en niks in die tonnel is verkeerd nie.
Wat die reël vaspen en wat DNS teruggee
'n Split-tunnel-reël is 'n statiese stelling oor bestemmings, gewoonlik uitgedruk as 'n voorvoegsel, 'n roete of 'n adreslys. Dit word op die oomblik van stuur teen die pakket se bestemming geëvalueer. 'n Gasheernaam is 'n opsoek wat 'n stel adresse met 'n leeftyd en 'n kas teruggee, en die antwoord kan verskil per oplosser, per navraagtipe en per minuut.
Daardie twee objekte onderhandel nooit met mekaar nie. Die reël pas steeds die voorvoegsel wat dit gekry het, die diens verander steeds die adres wat dit uitreik, en die gaping tussen hulle word stilweg groter. Dit is waarom die simptoom ná 'n verskaffermigrasie of 'n sertifikaathernuwing verskyn eerder as ná 'n konfigurasieverandering. Niemand het die tonnel geredigeer nie, so niemand kyk na die tonnel nie, en die diagnose dryf na die toepassing eerder as die beleid.
Drie maniere waarop die passing breek
Die ooglopende geval is 'n diens wat geskuif het: die operateur het dit her-adresseer, DNS het gevolg, en die uitsondering het nie. Die tweede is 'n adresfamilie wat die reël nooit gedek het nie, wat gebeur wanneer 'n naam AAAA-rekords begin teruggee wat 'n slegs-v4-uitsondering ignoreer. Die derde is 'n verskil in oplossers: 'n interne siening en 'n openbare siening kan verskillende adresse vir dieselfde naam teruggee, so die adres wat jou app gebruik is nie die een waarmee jy getoets het nie.
'n Gekasde verbinding is 'n vierde variant en dit is maklik om mis te kyk. Die toepassing praat dalk nog met 'n adres wat dit 'n uur gelede opgelos het, wat beteken jou vars opsoek en sy oop sokkel stem nie saam oor waar die diens woon nie.
Lees die bestemming wat die app werklik gebruik
Vra die bedryfstelsel en die soktabel, nie 'n blaaier-oortjie nie. Die opsoek antwoord waarheen die naam nou oplos, en die soktabel wys die adres waaraan die proses gekoppel is, wat ouer kan wees. Voer albei uit voordat jy 'n teorie vorm, want die verskil tussen hulle is self die antwoord in omtrent die helfte van die gevalle.
getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40Vergelyk dit dan met wat die reël dek. As die huidige adres buite die uitsondering val en die versoek steeds misluk, het jy die oorsaak gevind sonder om aan die tonnelkonfigurasie te raak. As die app aan 'n adres gekoppel is wat by die reël pas en die versoek steeds misluk, is die probleem ergens verby die tonnel en is dit die verkeerde ondersoek.
Herstel die meganisme, nie die simptoom nie
As die produk onderhoude domeingebaseerde sturing ondersteun, gebruik dit en volg sy gedokumenteerde verversings- en omvangsgedrag. Dit vervang 'n statiese raaiskoot met 'n onderhoude antwoord, ten koste daarvan dat jy daarop staatmaak dat die funksie werk soos gedokumenteer.
As die ontwerp op 'n statiese lys staatmaak, gee dit 'n eienaar en 'n opdateringsplan. Daardie plan moet sê hoe die adres ontdek word, wie die verandering goedkeur en hoe vinnig die lys na verwagting 'n verskaffermigrasie sal volg. 'n Lys sonder 'n eienaar is 'n toekomstige onderbreking met 'n bekende oorsaak.
Moenie die uitsondering na 'n groot naburige netwerk verbreed net om elke adres te vang wat jy tydens 'n kort toets gesien het nie. Dit is nie 'n regstelling nie; dit is 'n permanente verandering aan die veiligheidsgrens, en dit sal stilweg toelaat dat onverwante dienste die tonnel omseil vir solank die reël bestaan.
Verifieer albei helftes van die bedoeling
'n Split-tunnel-ontwerp het twee bedoelings, en 'n regstelling moet albei bewaar. Die beskermde diens moet deur die tonnel gaan, en die uitgeslote kategorieë moet om dit bly gaan. Toets 'n vars verbinding na die herstelde bestemming, en toets dan een ding wat veronderstel is om buite te bly.
curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'Teken die nuwe adres, die meganisme wat jy gekies het en die datum aan. Daardie nota is wat die volgende persoon keer om af te lei dat die VPN sy eie konfigurasie lukraak geïgnoreer het.