Kill switch VPN-sivukontille: estä liikenne, kun se pysähtyy

Sovelluskontilla, joka jakaa VPN-kontin verkkonimitilan, ei ole omaa rajapintaa, joten on helppo olettaa, ettei se voi lähettää mitään, kun tunneli epäonnistuu. Oletus on väärä siinä vikatilassa, jolla on merkitystä. Jos VPN-prosessi kuolee nimitilan jäädessä eloon, sovellus säilyttää sokettinsa ja nimitila säilyttää reittinsä, ja liikenne jatkuu sitä polkua pitkin, joka on vielä asennettu. Todellinen kill switch on selkeä suodatuspolitiikka sekä testit ajoympäristön elinkaaresta, ei käynnistysriippuvuus.

Miksi nimitilan jakaminen ei ole kill switch

Nimitilan jakaminen tarkoittaa, että sovellus käyttää VPN-kontin rajapintoja, osoitteita ja reititystaulua. Se poistaa sovelluksen itsenäisen polun verkkoon niin kauan kuin jaettu nimitila on ehjä, eikä se kerro mitään siitä, mitä tämä nimitila tekee, kun tunneli katoaa.

Composen riippuvuusehdot voivat viivästyttää sovelluksen käynnistymistä, kunnes riippuvuus on kunnossa. Se kattaa yhden hetken ajassa eikä mitään myöhempää vikaa, joten se on käynnistysjärjestyksen työkalu eikä jatkuva lähtöpalomuuri.

Miltä itse asiassa näyttää, kun kontti pysähtyy

Erottele kolme tapahtumaa. Kontin sisällä oleva VPN-prosessi voi kuolla kontin jatkaessa käynnissä. Kontti voi pysähtyä tai tulla poistetuksi, mikä tuhoaa nimitilan. Kontti voidaan luoda uudelleen, mikä rakentaa uuden nimitilan ja uudet säännöt.

Ensimmäisessä tapauksessa nimitila säilyy, oletusreitti voi edelleen osoittaa fyysiseen rajapintaan, ja sovellus jatkaa lähettämistä suoraan. Toisessa tapauksessa riippuvainen sovellus menettää yleensä yhteyden kokonaan, koska sen nimitila katosi. Kolmannessa tapauksessa sovellus voi yhdistää uudelleen tuoreeseen nimitilaan ennen kuin tunneli on valmis. Jokainen tapaus vaatii erilaisen testin, ja suunnittelu, joka kattaa vain siistin katkoksen, kattaa vähiten kiinnostavan.

Rakenna selkeä lähtöpolitiikka

Kirjoita politiikka jaetun nimitilan sisään, jotta se koskee sovelluksen paketteja. Muoto on oletushylkäys kapein poikkeuksin: loopback, tunnelin rajapinta sekä se tietty päätepisteen osoite ja portti, jota tunnelin kuljetus tarvitsee.

Päätepisteen poikkeuksen on oltava paikallaan ennen kuin tunneli nousee, muuten VPN-asiakasohjelma ei tavoita palvelintaan. Siksi sääntöjoukko sallii ulomman kuljetuksen nimenomaisesti sen sijaan, että sallisi fyysisen rajapinnan yleisesti. Lisää myös IPv6-säännöt, jos nimitilassa on IPv6-yhteys, koska vain IPv4:tä koskeva politiikka jättää toisen perheen avoimeksi.

DNS kuuluu myös politiikkaan. Jos sovellus selvittää nimiä vain tunnelin sisällä tavoitettavan resolverin kautta, hylkäyssääntö katkaisee selvityksen, kun tunneli on alhaalla, mikä on kill switchille oikea käytös. Päätä tietoisesti, haluatko sitä.

Testaa elinkaari, älä vain katkos

Lähetä tuore harmiton pyyntö, kun tunneli on kunnossa, tapa sitten VPN-prosessi ja lähetä toinen. Toista kontin pysäytyksen, uudelleenkäynnistyksen ja uudelleenluonnin jälkeen. Tuore pyyntö on tärkeä, koska olemassa oleva yhteys voi selvitä sääntömuutoksesta, joka estää uudet.

Älä luota terveystarkistukseen tai lähtö-IP:n hakuun estomekanismina. Tarkistus havainnoi tilaa ja raportoi sen; politiikka ohjaa liikennettä. Molemmat kuuluvat samaan käyttöönottoon, eivätkä ne korvaa toisiaan.

Kirjaa säännöt, jotta testi säilyy päivityksen yli

Kirjoita kunkin vikatapauksen odotettu lopputulos käyttöönoton dokumentaatioon yhdessä sen toteuttavien sääntöjen kanssa. Tämä kirjaus mahdollistaa saman testin ajamisen kuvapäivityksen tai ajoympäristön päivityksen jälkeen, jolloin nimitilan käytös tai oletusreitit voivat muuttua ilman, että kukaan muokkaa compose-tiedostoa.

Pidä VPN-päätepisteen vaatima ulompi polku erillään rajoittamattomasta sovelluksen lähdöstä ja pidä DNS ja IPv6 aiotussa kattavuudessa. Jos politiikka sallii mukavuuden vuoksi koko fyysisen rajapinnan, kill switch on poissa. Dockerin verkkodokumentaatio kuvaa jaetun nimitilan järjestelyn, jolle politiikka rakentuu, ja se on viite, joka tarkistetaan, kun ajoympäristön käytös on kyseenalainen.