Asiakas yrittää yhdistää uudelleen, eikä koneesta lähde mitään, vaikka sama profiili toimi vielä viime viikolla. Päätepisteen isäntänimi ratkeaa nyt toiseen osoitteeseen, ja lähtevä poikkeus nimeää yhä vanhan. Yksi vanhentunut lupa riittää muuttamaan toimivan kill switchin täydelliseksi katkokseksi, eikä se näy missään työpöydän tilamerkissä. Korjaus on pieni työnkulku, ei yhden rivin muutos.

Tunneli yhdistyy uudelleen, eikä sitten lähde mitään

Lähtevä sääntö, joka nimeää kohdeosoitteen, on tilannekuva, eivätkä DNS-vastaukset ole. Kun palveluntarjoaja vaihtaa osoitetta, paketti, jonka asiakas lähettää uutta peeriä kohti, ei vastaa mitään, ja oletuskielto pudottaa sen. Asiakas ilmoittaa tämän jälkeen aikakatkaisusta, mikä kuulostaa palvelimen ongelmalta eikä palomuurin ongelmalta.

Julkisen kyselyn palauttaman osoitteen kiinnittäminen saa tämän päivän toimimaan ja jättää huomisen rikki. Se on kertaluonteinen muutos, ei ylläpitokäytäntö.

Kuvaile poikkeus, jota todella tarkoitat

Aloita kirjoittamalla muistiin neljä arvoa, jotka sääntö tarvitsee: hyväksytty päätepisteen nimi tai osoitejoukko, kuljetus, kohdeportti ja liitäntä, jonka kautta paketti lähtee. Kaikki neljä ovat osa lupaa, ja mikä tahansa niistä voi olla väärin, vaikka sääntö näyttää yhä uskottavalta. Sääntö, joka on oikein kolmessa niistä, epäonnistuu täsmälleen samoin kuin sääntö, joka on väärin kaikissa neljässä. Kirjoita ne muistiin ennen komennon kirjoittamista, sillä sääntö on vain niin hyvä kuin sen takana oleva kuvaus.

Alla oleva komento näyttää muodon yhdelle IPv4 UDP -päätepisteelle kiinteällä yhteydellä. Korvaa molemmat arvot niillä, jotka olet vahvistanut käyttöönottoa vasten.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

Tämä lupa ei salli mielivaltaisia kohteita samalla portilla, ei luo kuuntelijaa eikä kata TCP:tä. UFW:n käsikirjasivu kuvaa, miten osoite, liitäntä ja protokolla rajaavat sääntöä, ja juuri se rajaus on koko pointti.

Päivitä se yhtenä työnkulkuna

Käsittele poikkeusta resurssina, jolla on omistaja ja siirtymä, älä komentona, jonka joku muistaa ajaa. Hanki ensin ehdokas käyttöönoton omasta ratkaisijasta ja päätepisteluettelosta ja määrittele tietoisesti, miten nimi ratkeaa ennen tunnelin olemassaoloa. Validoi ehdokas sitten aiottua protokollaa, porttia ja osoiteperhettä vasten ennen sääntökokonaisuuteen koskemista.

Asenna ensin uusi kapea lupa ja vahvista, että se latautui, sillä asiakkaan pyytäminen käyttämään osoitetta, jonka palomuuri yhä estää, tuottaa virheen, joka näyttää palvelinvialta. Jätä liittymättömät säännöt koskemattomiksi muutoksen aikana.

Tarkkaile asiakkaan siirtymää sen tuetun uudelleenyhdistämispolun kautta ja vahvista, minkä etäosoitteen se valitsi. Pelkän DNS:n päivittäminen ei siirrä olemassa olevaa socketia, ja päätepisteen pysyvyysasetus voi pitää asiakkaan vanhassa peerissä kauan sen jälkeen, kun tietue on muuttunut.

Poista lopuksi vanhentunut lupa tarkoituksella ja salli hyväksytty päällekkäisyysikkuna, kun vanha istunto on vielä aktiivinen. Vanhan merkinnän poistaminen liian aikaisin aiheuttaa lyhyen katkoksen; sen jättäminen ikuisesti jättää luvan, jota kukaan ei osaa selittää.

Poista vanha lupa tarkoituksella

Poistaminen on se kohta, jossa suurin osa riskistä on, koska vanha sääntö on ainoa asia, joka juuri nyt toimii. Jos ehdokkaan asennus epäonnistui, älä jatka äläkä poista merkintää, joka yhä kuljettaa liikennettä. Jos itse poistaminen epäonnistuu, merkitse vanhentunut lupa vanhentuneeksi sen sijaan, että julistaisit käytännön ajan tasalle.

Toista koko katsaus, kun yhteys vaihtuu Ethernetistä Wi-Fiin, kun kuljetus vaihtuu tai kun palvelu vaihtuu useiden osoitteiden välillä. Liitäntäkohtaisen säännön on tarkoitus lakata täsmäämästä verkkoyhteyden muutoksen jälkeen, ja se käytös on oikein, vaikka se näyttää regressiolta.

Todista sopimus sen jälkeen vaarattomalla liikenteellä. Hyväksytyn päätepisteen on oltava tavoitettavissa asennuksen aikana, suojatun sovelluksen on toimittava yhteyden muodostamisen jälkeen ja liittymättömän suoran liikenteen on pysyttävä estettynä katkoksen aikana. Sisällytä molemmat osoiteperheet ja yksi tarkoituksella epäonnistunut päivitysyritys, sillä yhden kiinnitetyn osoitteen muutoksen jälkeen onnistuva yhteys ei todista mitään noista tapauksista.

Aiheeseen liittyvät artikkelit