Split-tunneling vai yrityksen käytäntö: kumpi sääntö voittaa
Yrityksen suunnittelu voi vaatia hyväksytyn ulostulon, hallitun DNS:n tai päätepisteiden tarkistukset. Paikallinen ohitus on ristiriidassa suunnittelun kanssa, vaikka se saisi yhden sivuston latautumaan.
Yhden sovelluksen valitseminen split-tunnel-asiakasohjelmassa tuntuu paikalliselta mieltymykseltä, ja hallitulla laitteella se on lähempänä käytännön muutosta. Poikkeus siirtää liikennettä hyväksytyltä reitiltä, joka voi olla sama reitti, jota pitkin kulkevat hallittu DNS, suodatus ja lähdeosoite, jonka palvelu tunnistaa. Asiakasohjelma ei toimi väärin, kun se palauttaa muutoksesi; käyttöönotto tekee työtään.
Ennen kuin väittelet valintaruudusta, selvitä, mitä ominaisuutta käytäntö on olemassa suojaamaan.
Säännön takana oleva ominaisuus
Jotkin käyttöönotot reitittävät kaiken niin, että kaikki liikenne kulkee hyväksytyn yhdyskäytävän kautta. Toisille nimien selvitys on tärkeää, ja ne pitävät kyselyt yrityksen selvittäjällä paikallisen verkon sijaan. Kolmannet tarvitsevat vakaan lähdeosoitteen, jotta sisäiset palvelut voivat päättää vastaavatko ne lainkaan.
Neljäs ryhmä valvoo päätepisteen tilaa: levyn salauksen tila, päivitystaso, agentin kunto. Tunnelista jakaminen ei muuta sitä, kun taas ohitus, joka välttää agentin oman liikenteen, voi.
Nämä ovat neljä eri vaatimusta, ja jokaisen rikkoo eri poikkeus. Lue vaatimus ennen muutoksen ehdottamista, sillä sen kirjoittaja kertoo heti, mikä niistä pätee. Muutos, joka täyttää väärän, ei osta mitään.
Kaksi väitettä kannattaa hylätä varhain. Täysi tunnelointi ei anna ylläpitäjille jokaista selkokielistä sivua, koska sovellusten salaus ja päätepistevalvonta ratkaisevat, mikä on näkyvää. Split-tunneling ei myöskään ole yleisesti turvatonta, koska hallittu DNS, sovelluskohtaiset käytännöt ja päätepisteagentit voivat pitää reitistä riippumatta.
Suorita tarkistukset järjestyksessä
Alla oleva järjestys rajaa poikkeuksen pienimpään asiaan, joka todella epäonnistui. Pysähdy ensimmäiseen tarkistukseen, joka ei pidä, sillä myöhempi korjaus ei voi korvata aiempaa puutetta.
Kysy, mikä liikenne nyt ohittaa hyväksytyn yhdyskäytävän, ja vahvista sitten, että nimien selvitys saavuttaa yhä yrityksen selvittäjän. Tarkista, kunnioittaako kyseinen sovellus hätäkatkaisinta vai käyttikö se epäonnistuneen yrityksen suoralla reitillä. Katso sitten jaettuja palveluita: asiakirjakatselin tai päivitysvälittäjä voi viedä poikkeuksen pidemmälle kuin valintaruutu antaa ymmärtää. Kirjaa lopuksi, otetaanko käytäntö uudelleen käyttöön yhteyden muodostuksessa, koska se ratkaisee, jääkö paikallinen muutos voimaan.
Jokainen vastaus on tosiasia, ja poikkeushakemus tarvitsee tosiasioita. Väittely siitä, onko VPN ärsyttävä, ei ole yksi niistä. Kirjoita vastaukset muistiin ennen keskustelun alkua.
Pyydä kapeaa poikkeusta
Raportoi sovellus, kohde ja epäonnistunut toiminto tässä järjestyksessä. Pyyntö pitää yksi päivitysohjelma suoralla reitillä on arvioitavissa; pyyntö ohittaa tunneli koko selaimelle ei ole.
Kuvaile, mitä olet jo kokeillut ja mitä lokit näyttivät, ja osoita se profiilin omistavalle tiimille sen sijaan, että se menisi tukipalveluun vastaavalle. Hallitulla laitteella profiilin omistaja voi yleensä luoda tuetun poikkeuksen, joka kestää päivitykset, kun taas paikallinen reittimuutos ei voi.
Jos vastaus on ei, käsittele sitä suunnittelupäätöksenä, älä esteenä, joka kierretään. Seuraava katsaus on paikka avata se uudelleen, kun epäonnistunut toiminto on dokumentoitu ja liiketoiminnan syy liitetty. Sen kiertäminen riskeeraa enemmän kuin poikkeus koskaan oli arvoinen.
Tee poikkeuksesta kestävä
Hyväksytyn muutoksen jälkeen vahvista ne osat, jotka toimivat aiemmin, älä vain sitä osaa, joka oli rikki. Sisäisten nimien pitäisi selvityä yhä yrityksen selvittäjän kautta, yksityisten resurssien vastata, ja aiemmin epäonnistuneen tehtävän valmistua nyt.
resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status
Ensimmäinen komento todistaa, että selvittäjä vastaa yhä sisäiseen suffiksiin, ja toinen, että pyyntö saavuttaa sisäisen palvelun nykyiseltä reitiltä. Suorita ne uudelleen yhteyden muodostuksen jälkeen, sillä käytännön työntö voi hiljaa kumota muutoksen, joka näytti testissä vakaalta. Kaksi tulosteriviä lipun yhteyteen tallennettuna sulkee kehän. Ilman niitä poikkeus lepää jonkun muistin varassa sivusta, joka latautui kerran.
Kirjaa poikkeus, sen tarkoitus ja kattamat komponentit samaan paikkaan kuin käyttöönoton muistiinpanot. Dokumentoimaton poikkeus muuttuu seuraavan neljänneksen häiriöksi, ja dokumentoitu puolestaan todisteeksi siitä, että suunnittelu kestää todellisen työkuorman.