Split-tunnel dokumentācijai vajadzīgs DNS noteikums pie katra maršruta
Maršruts izlemj pēc adreses, risinātājs izlemj pēc nosaukuma. Dokumentējiet abus atlasītājus katram plūsmam, katru ar vienu testu, citādi piezīme neizdosies, kad DNS pārvietojas.
Split-tunnel piezīme, kas saka "biroja trafiks iet caur VPN", ir dokumentējusi vienu lēmumu un netieši pieņēmusi trīs citus. Pakešu slānī maršrutēšanas tabula izvēlas saskarni pēc galamērķa adreses; nosaukumu slānī risinātājs izvēlas serveri pēc vaicājuma, un šīs divas izvēles tiek veiktas neatkarīgi. Tāpēc pareizi dokumentēts prefikss joprojām var radīt mašīnu, kas iekšēju nosaukumu atrisina uz publisku adresi, vai neatrisina neko, kamēr maršruts izskatās nevainojams.
Divi atlasītāji, viens savienojuma mēģinājums
Kad lietotne savienojas ar files.corp.example, pirms paketes pastāvēšanas notiek divas meklēšanas. Risinātājs izlemj, kurš serveris saņems vaicājumu, izmantojot meklēšanas domēnus, maršrutēšanas domēnus katram savienojumam vai skaidru profila noteikumu. Pēc tam maršrutēšanas tabula izlemj, kur dosies iegūtā adrese, izmantojot garāko prefiksa atbilstību galamērķim.
Nekas nesaista šos divus lēmumus. Privāta zona var atbildēt ar 10.20.4.11, kamēr maršrutēšanas tabula sūta 10.20.0.0/16 tunelī, un savienojums darbojas. Apgrieziet jebkuru un tas neizdodas tā, ka izskatās kā otrs: pareiza DNS politika plus trūkstošs maršruts dod atrisinātu nosaukumu un taimautu, savukārt pareizs maršruts plus publisks risinātājs dod adresi, kas tīri maršrutējas uz nepareizo vietu.
Sadalītā horizonta DNS padara to asāku. Viens un tas pats nosaukums var atgriezt privātu adresi no iekšējā risinātāja un publisku adresi no uz internetu vērstā, tāpēc piezīme, kas reģistrē tikai prefiksu, nevar paredzēt, kuru adresi klients faktiski izmantos. Pierakstiet risinātāja ceļu, citādi adrese ir minējums.
Ko izlaiž piezīme tikai par maršrutu
Ieraksts tikai par maršrutu ir nederīgs visbiežākajai split-tunnel kļūdai: nosaukumiem. Lietotājs ziņo, ka iekšējais tīkls netiek ielādēts, tunelis ir pacelts un prefikss ir. Tam, kurš paņem biļeti, nav ieraksta, kuram risinātājam vajadzēja atbildēt, nav veida, kā atšķirt nepareizu meklēšanas sufiksu no bloķēta servera, un nav bāzes līnijas salīdzināšanai.
Otrais izlaidums ir izņēmumu saraksts. Split-tunnel dizainu nosaka gan tas, kas paliek ārpus tuneļa, gan tas, kas tajā ieiet, un izslēgtie diapazoni parasti salūzt pirmie, jo konkrētāks vietējais maršruts vai klienta puses filtrs var pārspēt nodomu, neaizskarot profilu.
Trešais ir tuneļa tālā puse. Klienta maršruts tikai liek paketi uz vada; vienam vēl jāpārsūta tā un jābūt atgriešanās ceļam. strongSwan pārsūtīšanas rokasgrāmata atgādina, ka pārsūtīšanas un ugunsmūra noteikumi vienā ir funkcijas daļa, nevis santehnika, ko var pieņemt.
Lauki, kas padara piezīmi izpildāmu
Viena rinda uz plūsmu, un plūsma ir galamērķis plus nosaukums plus īpašnieks. Šie ir lauki, kas iztur saskari ar reālu incidentu:
| 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 |
Rinda "kur tas dzīvo" ir tā, ko cilvēki izlaiž. Servera virzīts prefikss, klienta profila pievienots maršruts un čaulā ierakstīts maršruts atšķiras ar to, kas tos var mainīt, un ar to, vai tie iztur atkārtotu savienojumu. Bez šī lauka nākamais inženieris nevar pateikt, kuru no trim viņš skata.
Viens tests uz noteikumu, nevis viens uz tuneli
Katrai rindai vajadzīgas divas nekaitīgas pārbaudes: viena trenē maršrutu, otra – nosaukumu. Maršrutam pieprasiet kaut ko, kam jāšķērso tunelis, un apstipriniet ceļu, nevis sasniedzamību, piemēram tracert -d 10.20.4.11 Windows vai ip route get 10.20.4.11 Linux. Nosaukumam vaicājiet privāto nosaukumu un pierakstiet, kurš serveris atbildēja, izmantojot resolvectl query files.corp.example vai dig files.corp.example pret piezīmē nosaukto risinātāju.
Pievienojiet arī negatīvu gaidījumu: kam jānotiek, kad tunelis ir izslēgts. Izslēgtai lietotnei Android vai iOS ierīcē ar iespējotu bloķēšanu bez VPN var vispār nebūt savienojuma, un galddatora klients var atstāt to pašu lietotni strādājam, kamēr tunelis atkārtoti savienojas. Paredzētās atbildes pierakstīšana "VPN salauza manu lietotni" pārvērš pārbaudāmā apgalvojumā.
Glabājiet ierakstu kopā ar konfigurāciju
Glabājiet piezīmi blakus profilam, ko tā apraksta, un versionējiet to ar šo profilu. Dokuments viki, ko neviens neatjaunina, ir bauma; tabula tajā pašā krātuvē kā virzītie maršruti un risinātāja politika ir pārskatāma tajā pašā izmaiņā.
Kad kaut kas salūzt, pirms pievienojat vēl vienu izņēmumu, salīdziniet lietoto maršrutu un faktisko risinātāju ar ierakstu. Divi no trim biežajiem cēloņiem — vecs nosaukumvietas noteikums un palīgprocess ārpus lietotnes politikas — izskatās tieši kā VPN bojājums un ir neredzami, ja piezīme uzskaita tikai prefiksus.
Pirms pasludināt piezīmi pabeigtu, apstipriniet, ka tā rakstiski atbild uz šo: kurš prefikss, kurai adrešu saimei; kura privātā nosaukumvieta, kura risinātāja atbildēta; kuri nosaukumi apzināti paliek publiski; kur katrs noteikums ir konfigurēts un kam tas pieder; un tā viena komanda, kas pierāda maršrutu, un tā, kas pierāda nosaukumu. Ja kaut kas no tā trūkst, nākamais incidents tiks diagnosticēts no nulles.