Split-tonnel-dokumente het 'n DNS-reël langs elke roete nodig
'n Roete besluit op adres, 'n resolver besluit op naam. Dokumenteer albei keuses per vloei, elk met een toets, of die notas faal wanneer DNS verskuif.
'n Split-tonnel-nota wat sê "kantoorverkeer gaan deur die VPN" het een besluit gedokumenteer en drie ander geïmpliseer. Op die pakketvlak kies 'n roetekaart 'n koppelvlak op bestemmingsadres; op die naamvlak kies 'n resolver 'n bediener op navraag, en die twee keuses word onafhanklik gemaak. Dis hoekom 'n korrek gedokumenteerde voorvoegsel steeds 'n masjien kan lewer wat 'n interne naam na 'n openbare adres oplos, of niks oplos terwyl die roete perfek lyk.
Twee keuses, een verbindingspoging
Wanneer 'n toepassing aan files.corp.example, gebeur twee opsoeke voordat 'n pakket bestaan. Die resolver besluit watter bediener die navraag ontvang, met behulp van soekdomeine, roetedomeine per skakel of 'n eksplisiete profielreël. Die roetekaart besluit dan waar die resulterende adres heen gaan, met die langste-voorvoegsel-ooreenstemming teen die bestemming.
Niks verbind daardie twee besluite nie. 'n Privaat sone kan antwoord met 10.20.4.11 terwyl die roetekaart 10.20.0.0/16 in die tonnel stuur, en die verbinding werk. Draai enige een om en dit faal op 'n manier wat soos die ander lyk: DNS-beleid reg plus 'n ontbrekende roete gee 'n opgeloste naam en 'n tydsverloop, terwyl 'n korrekte roete plus 'n openbare resolver 'n adres gee wat netjies na die verkeerde plek roeteer.
Split-horison-DNS maak dit skerper. Dieselfde naam kan 'n privaat adres van die interne resolver en 'n openbare adres van die internetgerigte een teruggee, so 'n nota wat net die voorvoegsel opteken, kan nie voorspel watter adres die kliënt werklik sal gebruik nie. Skryf die resolver-pad neer, anders is die adres 'n raaiskoot.
Wat 'n slegs-roete-nota uitlaat
'n Slegs-roete-rekord is onbruikbaar vir die mees algemene split-tonnel-fout: name. Die gebruiker meld dat die intranet nie laai nie, die tonnel is op, en die voorvoegsel is daar. Wie die kaartjie oorneem, het geen rekord van watter resolver moes geantwoord het nie, geen manier om 'n verkeerde soek-agtervoegsel van 'n geblokkeerde bediener te onderskei nie, en geen basislyn om teen te vergelyk nie.
Die tweede weglating is die uitsonderingslys. 'n Split-tonnel-ontwerp word net soveel bepaal deur wat buite die tonnel bly as deur wat daarby inkom, en die uitgeslote reekse is gewoonlik die wat eerste breek, want 'n meer spesifieke plaaslike roete of 'n kliëntkant-filter kan die bedoeling oorheers sonder om die profiel te raak.
Die derde is die verre kant van die tonnel. 'n Kliëntroete plaas net die pakket op die draad; die poort moet dit steeds aanstuur en 'n pad terug hê. strongSwan se aanstuur-handleiding is 'n herinnering dat aanstuur- en brandmuurreëls op die poort deel van die kenmerk is, nie deel van die loodgieterswerk wat jy kan aanvaar nie.
Die velde wat die nota uitvoerbaar maak
Een ry per vloei, en 'n vloei is 'n bestemming plus 'n naam plus 'n eienaar. Dit is die velde wat 'n werklike voorval oorleef:
| 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 |
Die ry "waar dit woon" is die een wat mense oorslaan. 'n Voorvoegsel wat deur die bediener gestuur word, 'n roete wat deur 'n kliëntprofiel bygevoeg word en 'n roete wat in 'n skulp getik word, verskil in wie dit kan verander en in of dit 'n herverbinding oorleef. Sonder daardie veld kan die volgende ingenieur nie sê na watter van die drie hy kyk nie.
Een toets per reël, nie een per tonnel nie
Elke ry het twee skadelose kontroles nodig: een wat die roete oefen en een wat die naam oefen. Vir die roete, vra iets wat die tonnel moet kruis en bevestig die pad eerder as die bereikbaarheid, byvoorbeeld tracert -d 10.20.4.11 op Windows of ip route get 10.20.4.11 op Linux. Vir die naam, vra die privaat naam en teken op watter bediener geantwoord het, met resolvectl query files.corp.example of dig files.corp.example teen die resolver wat die nota noem.
Voeg ook 'n negatiewe verwagting by: wat moet gebeur wanneer die tonnel af is. 'n Uitgeslote toepassing op 'n Android- of iOS-toestel met blokkeer-sonder-VPN geaktiveer, het dalk glad geen verbinding nie, en 'n lessenaarkliënt kan dieselfde toepassing laat werk terwyl die tonnel herverbind. Om die bedoelde antwoord op te teken, verander "die VPN het my toepassing gebreek" in 'n nagegaanbare stelling.
Hou die rekord by die konfigurasie
Stoor die nota langs die profiel wat dit beskryf en wees dit saam met daardie profiel. 'n Dokument in 'n wiki wat niemand bywerk nie, is 'n gerug; 'n tabel in dieselfde bewaarplek as die gestuurde roetes en die resolver-beleid kan in dieselfde verandering nagegaan word.
Wanneer iets breek, vergelyk die toegepaste roete en die effektiewe resolver met die rekord voordat jy nog 'n uitsondering byvoeg. Twee van die drie algemene oorsake — 'n ou naamruimte-reël en 'n hulpproses buite die toepassingsbeleid — lyk presies soos 'n VPN-fout en is onsigbaar as die nota net voorvoegsels lys.
Voordat jy die nota as klaar beskou, bevestig dat dit hierdie dinge skriftelik beantwoord: watter voorvoegsel, vir watter adresfamilie; watter privaat naamruimte, deur watter resolver beantwoord; watter name doelbewus openbaar bly; waar elke reël gekonfigureer is en wie dit besit; en die een opdrag wat die roete bewys en die een wat die naam bewys. As enige van dié ontbreek, sal die volgende voorval van nuuts af gediagnoseer word.