„Split-tunnel“ dokumentacijai reikia DNS taisyklės prie kiekvieno maršruto
Maršrutas sprendžia pagal adresą, resolveris – pagal pavadinimą. Dokumentuokite abu selektorius kiekvienam srautui, kiekvieną su vienu testu, kitaip pastaba žlugs, kai DNS pasislinks.
Split-tunnel pastaba, sakanti „biuro srautas eina per VPN“, dokumentavo vieną sprendimą ir numanė tris kitus. Paketų lygmenyje maršrutų lentelė sąsają renkasi pagal paskirties adresą; pavadinimų lygmenyje resolveris serverį renkasi pagal užklausą, ir šie du pasirinkimai daromi nepriklausomai. Todėl teisingai dokumentuotas prefiksas vis tiek gali sukurti mašiną, kuri vidinį pavadinimą išsprendžia į viešą adresą, arba nieko neišsprendžia, kol maršrutas atrodo tobulas.
Du selektoriai, vienas prisijungimo bandymas
Kai programa prisijungia prie files.corp.example, prieš atsirandant paketui įvyksta dvi paieškos. Resolveris nusprendžia, kuris serveris gaus užklausą, naudodamas paieškos domenus, maršrutų domenus kiekvienai jungčiai arba aiškią profilio taisyklę. Tada maršrutų lentelė nusprendžia, kur keliaus gautas adresas, naudodama ilgiausią prefikso atitikimą paskirčiai.
Niekas nesusieja šių dviejų sprendimų. Privati zona gali atsakyti 10.20.4.11, o maršrutų lentelė siunčia 10.20.0.0/16 į tunelį, ir ryšys veikia. Apverskite bet kurį ir jis žlunda taip, kad atrodo kaip kitas: teisinga DNS politika ir trūkstamas maršrutas duoda išspręstą pavadinimą bei laiko limitą, o teisingas maršrutas ir viešas resolveris duoda adresą, kuris švariai maršrutizuojamas į netinkamą vietą.
Padalinto horizonto DNS tai padaro aštresnį. Tas pats pavadinimas gali grąžinti privatų adresą iš vidinio resolverio ir viešą adresą iš į internetą nukreipto, todėl pastaba, fiksuojanti tik prefiksą, negali numatyti, kurį adresą klientas iš tikrųjų naudos. Užrašykite resolverio kelią, kitaip adresas yra spėjimas.
Ką praleidžia vien tik maršruto pastaba
Vien tik maršruto įrašas netinka dažniausiai split-tunnel klaidai: pavadinimams. Naudotojas praneša, kad vidinis tinklas neįkeliamas, tunelis pakeltas ir prefiksas yra. Kas paima bilietą, neturi įrašo, kuris resolveris turėjo atsakyti, neturi būdo atskirti neteisingą paieškos priesagą nuo užblokuoto serverio ir neturi pradinės linijos palyginimui.
Antrasis praleidimas yra išimčių sąrašas. Split-tunnel dizainą lemia tiek tai, kas lieka už tunelio, tiek tai, kas į jį patenka, o išbraukti diapazonai paprastai lūžta pirmieji, nes konkretesnis vietinis maršrutas arba kliento pusės filtras gali panaikinti ketinimą neliesdamas profilio.
Trečiasis yra tolimoji tunelio pusė. Kliento maršrutas tik padeda paketą ant laido; šliuzas vis tiek turi jį persiųsti ir turėti grįžimo kelią. strongSwan persiuntimo vadovas primena, kad persiuntimo ir ugniasienės taisyklės šliuze yra funkcijos dalis, o ne santechnika, kurią galima laikyti savaime suprantama.
Laukai, kurie padaro pastabą vykdomą
Viena eilutė srautui, o srautas yra paskirties vieta plius pavadinimas plius savininkas. Tai laukai, kurie atlaiko susidūrimą su tikru 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 |
Eilutė „kur jis gyvena“ yra ta, kurią žmonės praleidžia. Serverio stumiamas prefiksas, kliento profilio pridėtas maršrutas ir shell'e įvestas maršrutas skiriasi tuo, kas gali juos pakeisti ir ar jie atlaiko prisijungimą iš naujo. Be šio lauko kitas inžinierius negali pasakyti, kurį iš trijų jis mato.
Vienas testas taisyklei, o ne vienas tuneliui
Kiekvienai eilutei reikia dviejų nekenksmingų patikrų: viena treniruoja maršrutą, kita – pavadinimą. Maršrutui paprašykite ko nors, kas turi kirsti tunelį, ir patvirtinkite kelią, o ne pasiekiamumą, pavyzdžiui tracert -d 10.20.4.11 Windows sistemoje arba ip route get 10.20.4.11 Linux sistemoje. Pavadinimui užklauskite privatų pavadinimą ir užrašykite, kuris serveris atsakė, naudodami resolvectl query files.corp.example arba dig files.corp.example prieš pastaboje nurodytą resolverį.
Pridėkite ir neigiamą lūkestį: kas turėtų nutikti, kai tunelis išjungtas. Pašalinta programa Android ar iOS įrenginyje su įjungtu blokavimu be VPN gali visai neturėti ryšio, o darbalaukio klientas gali palikti tą pačią programą veikiančią, kol tunelis jungiasi iš naujo. Numatomo atsakymo užrašymas „VPN sugadino mano programą“ paverčia patikrinamu teiginiu.
Laikykite įrašą kartu su konfigūracija
Saugokite pastabą šalia profilio, kurį ji aprašo, ir versijuokite ją su tuo profiliu. Dokumentas viki, kurio niekas neatnaujina, yra gandas; lentelė tame pačiame saugykloje kaip stumiami maršrutai ir resolverio politika gali būti peržiūrėta tame pačiame pakeitime.
Kai kas nors sugenda, prieš pridėdami dar vieną išimtį palyginkite taikomą maršrutą ir veiksmingą resolverį su įrašu. Dvi iš trijų dažnų priežasčių – sena vardų erdvės taisyklė ir pagalbinis procesas už programos politikos ribų – atrodo lygiai kaip VPN gedimas ir yra nematomos, jei pastaba išvardija tik prefiksus.
Prieš pavadindami pastabą baigta, patvirtinkite, kad ji raštu atsako į tai: kuris prefiksas, kuriai adresų šeimai; kuri privati vardų erdvė, kurio resolverio atsakoma; kurie pavadinimai sąmoningai lieka vieši; kur kiekviena taisyklė sukonfigūruota ir kas ją valdo; ir ta viena komanda, kuri įrodo maršrutą, bei ta, kuri įrodo pavadinimą. Jei ko nors trūksta, kitas incidentas bus diagnozuojamas nuo nulio.