VPN-päätepisteiden sallittujen luettelo: unohtamasi DNS-päivitys

vpn.example.com:n kirjoittaminen palomuuripoikkeukseen tuntuu DNS-tilaukselta. Yleensä tapahtuu käännös lataushetkellä, minkä jälkeen sääntö pitää osoitteita eikä mikään päivitä niitä. Kaksi komponenttia jakaa nyt työn: vastaava ratkaisija ja tallentava palomuuri. Useimmat päätepisteiden katkokset alkavat siitä, mihin tätä luovutusta ei koskaan suunniteltu.

Isäntänimi säännössä ei ole elävä tilaus

Jotkin työkalut ratkaisevat nimen konfiguraation latautuessa; toiset pitävät isäntänimeä ja ratkaisevat sen uudelleen oman aikataulunsa mukaan; vielä toiset hyväksyvät vain osoitteita. Näkyvä konfiguraatio kertoo harvoin, mikä tapaus on kyseessä. Dokumentaation esimerkit olettavat yleensä lataushetken tapauksen, minkä vuoksi ero yllättää ihmiset muuton aikana. Lue toteutuksen käyttäytyminen ennen kuin oletat osoitteenmuutoksen huomattavan, koska vanhentunut sallittujen luettelo näyttää täsmälleen samalta kuin toimiva kunnes päätepiste siirtyy.

Sääntö, joka nimeää oikean isännän, voi silti sallia väärän osoitteen. Tämä aukko on myytti, ei kirjoitusvirhe.

Välimuistin TTL ei ole palomuurisi ajastin

DNS-tietueilla on elinaika, ja ratkaisijat välimuistittavat vastauksia sen ajan. DNS-määritys määrittelee tämän välimuistikäyttäytymisen, mutta se koskee DNS-tietoja, ei palomuurin erillistä osoitevarastoa. Lyhyt TTL ei luo päivitystehtävää sinne, missä sellaista ei ole. Välimuistitus tapahtuu myös useammalla kuin yhdellä kerroksella, joten päätteen näkemä vastaus ei välttämättä ole se, jonka palomuuri näki.

Kysy varsinaiselta tuotteelta kolme kysymystä: milloin se ratkaisee, mihin se tallentaa tuloksen ja mikä laukaisee päivityksen. Jos vastaus on vain käynnistyksessä, pitkäikäinen istunto voi elää pidempään kuin osoite, johon se hyväksyttiin.

dig +short vpn.example.com
resolvectl query vpn.example.com

Suunnittele päivitys ja epäonnistuminen yhtenä käytäntönä

Ylläpidettävä poikkeus tarvitsee eksplisiittiset vastaukset: mikä laukaisee päivityksen ennen kuin asiakas valitsee uuden osoitteen, miten sallittu joukko muuttuu avaamatta laajaa väliaikaista ikkunaa ja milloin vanhentuneet merkinnät poistetaan. Kirjoita vastaukset säännön viereen.

Valitse epäonnistumiskäyttäytyminen tietoisesti. Vanhan osoitteen pitäminen voi säilyttää istunnon ja jättää vanhentuneen luvan; joukon tyhjentäminen voi estää palautumisen. Kumpikaan ei saisi olla epäonnistuneen haun satunnainen tulos. Kirjoita valittu käyttäytyminen runbookiin, jotta seuraava operaattori ei improvisoi paineen alla.

Pidä myös käynnistyksen DNS kapeana. Ehdoton julkisen ratkaisijan poikkeus on suora DNS-reitti kaikelle, mihin se osuu, ei vain päätepisteen nimelle.

Todista päätepisteen muutos, älä ensimmäistä yhteyttä

Käytä asiakkaan tuettua hallintaohjelmaa, jos se jo koordinoi ratkaisua ja estoa. Sivuston hallitsemassa PF-isännässä pidä sivuston omistus ja palautumissuunnitelma sen sijaan, että kopioisit isäntänimitaulun syntaksia toiselta alustalta, jolla on erilainen elinkaarikäyttäytyminen.

Hyväksytyllä, harmittomalla testillä vertaa asiakkaan valitsemaa osoitetta aktiiviseen sallittuun joukkoon ennen kontrolloitua muutosta ja sen jälkeen. Kata epäonnistunut haku, sellaisen merkinnän poistaminen, joka ei enää ole kelvollinen, ja tuettuna eri osoiteperhe. Aiotun tunnelin pitäisi palautua, kun taas riippumaton suora liikenne pysyy käytännön alla. Onnistunut ensimmäinen yhteys todistaa vain, että alkuperäinen käännös sattui olemaan oikein.