Sovelluskohtaiset VPN-poikkeukset rikkoutuvat, kun jaettu palvelu hakee tiedot

Suljet yhden sovelluksen VPN:n ulkopuolelle, ja sen tarvitsema lataus epäonnistuu edelleen, tai pahempaa, se alkaa toimia ja jokin asiaan kuulumaton pysähtyy. Näkyvä ikkuna ei välttämättä ole prosessi, joka avaa jokaisen yhteyden: sovellus voi antaa työn apurille, taustalla toimivalle siirtopalvelulle tai kokonaan toiselle paketille. Siksi sovelluskohtainen sääntö tarvitsee alustan todellisen identiteettimallin eikä tuttua käynnistystiedoston nimeä. Alla olevat tarkistukset alkavat havainnosta ja palaavat siihen, joka pyynnön todella lähetti.

Näissä tiketeissä menee yleensä kaksi asiaa yhtä aikaa pieleen: väärä komponentti suljetaan pois, eikä poikkeusta koskaan kavenneta jälkeenpäin.

Etsi prosessi, älä ikkunaa

Toista epäonnistunut toiminto ja tunnista prosessi tai paketti, joka omistaa yhteyden sen tapahtuessa. Windowsissa tämä on eri kysymys kuin se, millä ikkunalla on kohdistus, koska taustasiirron voi välittää palvelu, joka toimii oman identiteettinsä alla. Linuxissa ja macOS:ssä sama jako näkyy apuprosesseina ja järjestelmän daemoneina.

Kirjoita kolme yksityiskohtaa: suoritettavan tiedoston tai paketin identiteetti, kohde, johon se oli yhteydessä, ja hetki työnkulussa, jolloin se tapahtui. Alussa epäonnistuva lataus on usein toisen komponentin metatietojen haku kuin puolivälissä epäonnistuva lataus. Pelkkä tämä ero riittää yleensä oikean identiteetin valintaan ennen kuin kosket sääntöön. Jos identiteetti osoittautuu sovelluksen sijaan palveluksi, tuo yksi tosiasia muuttaa koko säännön, joten selvitä se ensin.

Jos et voi havainnoida prosessia, koska toiminto on liian lyhyt, toista se suuremmalla kuormalla tai hitaammalla kohteella. Tavoitteena on yksi toistettava havainto, ei teoria siitä, mikä apuri on mukana.

Käsittele DNS:ää omana polkunaan

Järjestelmän nimien selvitys ei ehkä seuraa poissuljettua sovellusta lainkaan, minkä vuoksi poissuljettu selain voi yhä epäonnistua yksityisessä isäntänimessä, vaikka sen liikenne on oikein tunnelin ulkopuolella. Selain oli poissuljettu; selvittäjä ei ollut.

Tarkista, mitä alusta tekee DNS:lle, kun sovelluskohtainen sääntö on voimassa, ja tarkista se erikseen HTTP-pyynnöstä. Jos selvittäjä on jaettu palvelu, se palvelee jokaista laitteen sovellusta, joten harkitsemasi poikkeus tavoittaa paljon laajemman yleisön kuin testaamasi.

Kirjaa, mikä selvittäjä vastasi ja minkä liittymän kautta. Tämä yksi havainto ratkaisee suuren osan raporteista ”sovellus on poissuljettu, mutta nimi ei selviä”, joten pidä se tiketin mukana.

Älä laajenna jaettua apuria

Jaettu palvelu tekee työtä useille sovelluksille, joten sen poissulkeminen yhden työnkulun korjaamiseksi muuttaa myös asiaan kuulumatonta liikennettä. Windowsin Background Intelligent Transfer Service on hyvä esimerkki muodosta: se on infrastruktuuria, jota monet sovellukset voivat käyttää, eikä sen identiteetti ole siirtoa pyytäneen sovelluksen identiteetti.

Tarkista asiakkaan tukema sääntömalli ja organisaation vaatimukset ennen poikkeuksen lisäämistä. Kysy, mikä muu käyttää komponenttia, ja voidaanko kirjoittamasi sääntö ilmaista kohteisiin eikä jaettuun prosessiin nähden.

Jos vaatimusta ei voi lainkaan ilmaista sovellusrajana, kohdeperusteinen käytäntö tai muu hyväksytty ratkaisu voi olla ymmärrettävämpi ja turvallisempi kuin kasvava apuripoikkeusten luettelo.

Testaa koko työnkulku, älä epäonnistuvaa vaihetta

Aja aiottu tehtävä tuoreella pyynnöllä alusta loppuun tuetun muutoksen jälkeen. Aja sitten toinen työnkulku, joka käyttää jaettua komponenttia, sillä siinä laaja ohitus ilmoittaa itsestään. Korjaus, joka korjaa ensimmäisen ja rikkoo toisen hiljaa, ei ole korjaus. Säilytä molemmat tulokset tiketissä ja nimeä toinen työnkulku selvästi, jotta katselmoija voi toistaa sen.

Pidä testi pienenä ja toistettavana: sama kohde, sama tili, samat ehdot. Jos toista työnkulkua ei ole dokumentoitu, kysy sen omistajalta, mistä se riippuu, ennen kuin päätät muutoksen olevan turvallinen.

Jätä syy, älä nimiluetteloa

Dokumentoi komponentti, työnkulku jota se palvelee ja syy sen poissulkemiseen. Luettelo apurien nimistä ilman liitettyä tarkoitusta muuttuu ylläpitokelvottomaksi kahden julkaisusyklin kuluessa, ja seuraava insinööri poistaa väärän merkinnän sitä siivotessaan.

Yksi rivi poikkeusta kohden riittää: mitä ilman sitä rikkoutuu, kuka työnkulun omistaa ja milloin se viimeksi varmennettiin. Nuo kolme kenttää muuttavat salaperäisen luettelon käytännöksi, jota joku voi puolustaa.