’n VPN-domeinreël breek wanneer ’n CDN sy adresse verander

Jy kopieer die adres uit een opsoektog in jou roetereël, die werf werk, en ’n week later werk dit nie meer nie. Niks aan die reël het verander nie. Die diens het na ’n ander randadres geskuif, die kliënt het ’n ander gasheernaam opgelos, of die sessie het na IPv6 oorgeskakel. Die besluit voor jou is of ’n naamgebaseerde reël of ’n eksplisiete reeks die regte instrument vir hierdie diens is, en drie voorwaardes beslis dit. Wat volg, skei die naam van die adres, want net een van hulle is stabiel.

Waarom een opsoektog nie ’n inventaris is nie

’n Inhoudafleweringsnetwerk antwoord met ’n adres wat vir die oplosser, die streek en die oomblik gekies is. Vra twee keer uit verskillende netwerke en jy kan verskillende antwoorde kry. Vra een keer en behandel die antwoord as die diens se adreslys, en die reël wat jy skryf is ’n momentopname eerder as ’n reël. Dit is die hele probleem daarmee om ’n DNS-antwoord as konfigurasie te behandel.

Daar is ’n tweede leemte. Een sigbare gasheernaam dek selde die hele toepassing, want aanmelding, media en API-verkeer gebruik dikwels aparte name. ’n Reël wat uit die adresbalk se gasheernaam gebou is, kan die bladsy dek en die video mis, wat as ’n gedeeltelike fout eerder as ’n roeteringsfout gelees word.

Die derde leemte is die adresfamilie. ’n Reël wat net v4 ondersteun, sê niks oor die AAAA-rekord wat die kliënt moontlik verkies nie.

Drie voorwaardes wat bepaal of dit ’n domeinreël of reekse moet wees

Eerstens, publiseer die diens ’n stabiele stel voorvoegsels wat jy kan besit en dokumenteer? As dit wel doen, is eksplisiete reekse eerlik en goedkoop. As dit nie doen nie, is ’n domeinreël die enigste meganisme wat die diens kan volg.

Tweedens, verfris jou kliënt se domeinmeganisme? ’n Reël wat een keer by verbinding oplos en nooit weer nie, is ’n momentopname met beter handelsmerk. Derdens, dek die meganisme subdomeine en albei adresfamilies, of net die name wat jy getik het?

Beantwoord daardie drie en die keuse is gewoonlik duidelik. Om te raai lewer ’n reël wat in toetsing werk en in produksie faal.

Toets ’n sessie, nie ’n bladsy nie

Laai die bladsy, en voer dan die handeling uit wat saak maak: meld aan, begin speel, laai ’n lêer op. Elkeen van dié kan ’n ander gasheer bereik, en die een wat faal, is die een wat jou reël gemis het.

Maak ’n lys van wat die sessie werklik kontak, eerder as wat die bladsy wys:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

Hou die oplosser sigbaar tydens die vergelyking, want ’n reël wat van een oplosser werk en van ’n ander faal, vertel jou van die CDN se antwoord, nie van die tonnel nie. ’n Kort TTL beteken ook dat die antwoord wat jy aangeteken het, ’n rakleeftyd het.

Wat elke meganisme werklik dek

Die twee meganismes lyk in ’n instellingsbladsy verwisselbaar en gedra hulle onderlangs anders.

’n Kernadresroete pas by voorvoegsels. Dit het geen idee wat ’n gasheernaam is nie, so dit kan nie ’n diens volg wat adresse verander nie. ’n Domeinreël los name op en roeteer die resultaat, wat die diens volg maar afhang van die oplosser, die verfrissingsgedrag en die kliënt se hantering van subdomeine, so ’n reël wat name volg, moet getoets word met die oplosser wat die kliënt werklik gebruik.

Nie een is ’n superset van die ander nie, en daarom veroorsaak dit verwarring later as jy hulle sonder ’n nota meng.

Hertoets nadat die diens verander het

Na ’n kliëntopdatering of ’n diensverandering, voer dieselfde sessietoets weer uit. ’n Adreslys wat voorheen gewerk het, is bewyse oor daardie tydperk, nie ’n permanente inventaris van die diens se infrastruktuur nie.

Skryf neer watter meganisme watter gasheernaam dek, en die datum toe jy dit laas geverifieer het.

Daardie nota is die verskil tussen ’n reël wat jy kan verdedig en ’n reël wat niemand durf aanraak nie. As die diens sy eie voorvoegsellys publiseer, gebruik dit en noem die datum. As dit nie doen nie, sê so, en hou die domeinreël met sy verfrissingsgedrag daarby geskryf.