Varmista, että jaettu tunneli toimii: yksi IP-tulos ei ole testi

Yksi IP-osoitteen näyttävä selainsivu ei todista jaetusta tunnelista juuri mitään. Näkyvä osoite voi olla oikea väärästä syystä, eikä poissuljettua virtaa koskaan testata sillä. Kirjaa odotettu tulos ennen testiä: minkä sovelluksen tai kohteen pitäisi käyttää tunnelia, minkä pysyä suorana ja minkä pitäisi pysähtyä, kun tunneli epäonnistuu. Ilman tätä suunnitelmaa mikä tahansa uskottava luku näyttää onnistumiselta.

Myytti: osoitehaku todistaa kattavuuden

IP-tarkistus vastaa yhteen kysymykseen: mitä ulkomaailma näkee yhdestä sovelluksesta yhdellä hetkellä. Se ei kerro mitään sisäisestä etuliitteestä, toisesta selainprofiilista tai nimestä, joka pitäisi ratkaista yksityisesti. Se ei kerro mitään epäonnistumisestakaan, ja juuri se on jaetun tunnelin suunnittelun puoli, joka hajoaa tuotannossa.

Osoitesivu ei voi näyttää myöskään reittiä, ratkaisijaa tai vikakäytäntöä. Kohtele sitä yhtenä havaintona, ei tuomiona.

Testaa mukana oleva ja poissuljettu virta

Lähetä vaaraton pyyntö sovelluksesta, jonka pitäisi olla mukana, tai etuliitteeseen, jonka odotat kulkevan tunnelin kautta, ja kirjaa lähde, kohde, osoiteperhe ja havaittu polku. Tee sama virralle, jonka pitäisi pysyä suorana. Poissuljettu puoli on se, jonka ihmiset ohittavat, ja se on ainoa todiste siitä, että jako on tahallinen eikä sattumanvarainen. Apuprosessi voi kantaa erillistä käytäntöidentiteettiä, joten testaa prosessissa, joka omistaa pistokkeen.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Siksi väärässä sovelluksessa tehty testi voi näyttää suunnittelun tarkoituksen vastakohdan. Kirjaa neljä kenttää molemmille puolille ennen minkään johtopäätöksen tekemistä.

Lisää DNS ja vikatilanne

Kysy järjestelmän ratkaisijalta ja ratkaisijalta, jota sovellus käyttää, ja vertaa sitten näitä vastauksia lähtöosoitteeseen, jonka sivusto raportoi. Kaksi kerrosta voivat olla tahallisesti eri mieltä, eikä yksi selainhaku testaa käyttöjärjestelmän käytäntöä. Kuori tekee vertailusta toistettavan: Katkaise tunneli tahallaan ja tee sitten pyyntö, jota selain ei ole välimuistiin tallentanut; välimuistista tarjottu sivu ei kerro sinulle mitään siitä, kumpaan suuntaan varareitti meni. Kirjaa, mitä todella tapahtui, ei sitä, mitä suunnittelu ennusti.

curl -s https://ifconfig.me
nslookup intranet.example

Suljetusti epäonnistuva jaettu tunneli ja avoimesti epäonnistuva näyttävät samoilta, kunnes katkaiset tunnelin tahallaan. Kirjaa, mitä käyttäytymistä havaitsit, ei sitä, mitä odotit.

Toista tilan muutoksen jälkeen

Toista samat havainnot uudelleenyhdistämisen, verkon vaihdon ja asiaankuuluvan sovelluspäivityksen jälkeen. Tallennettu poissulkeminen voi jatkaa osoittamista polkuun tai sovellusidentiteettiin, jota ei enää ole, ja suunnittelu lakkaa hiljaa vastaamasta dokumentaatiotaan. Nämä kolme tapahtumaa ovat paikkoja, joissa jaetut tunnelit ajautuvat, ja jokainen niistä on halpa testata uudelleen. Testi, joka ajetaan vain kerran käyttöönotossa, kuvaa konfiguraatiota, jota ei enää ole.

Jos tulos poikkeaa, etsi säännön omistaja ja käsittelyvaihe ennen usean asetuksen muuttamista kerralla. Viiden asian muuttaminen ja yhden tuloksen havainnointi ei ole diagnoosi, se on uusi konfiguraatio.

Mitä tuloksen pitäisi osoittaa

Sido havainnot käytäntöön ja asiakasversioon, jota todella testasit. Tavoitteena on osoittaa, että tämä käyttöönotto vastaa sitä kattavuutta, jonka se väittää, ei että jokainen tuleva sovellus on yksityinen. Se on kapeampi väite, ja juuri sitä voit todella tukea todisteilla. Kirjaa väite, versio ja neljän kentän tulokset muutosrekisteriin.

Silloin seuraava arvioija voi sanoa, muuttuiko suunnittelu vai testi. Jaettu tunneli on varmennettu, kun molemmat puolet, ratkaisijan jako ja vikakäyttäytyminen vastaavat sitä, minkä kirjasit alussa. Yksi IP-tulos ei varmenna yhtään niistä.