VPN-verkkotunnussääntö hajoaa, kun CDN vaihtaa osoitteitaan

Kopioit osoitteen yhdestä kyselystä reitityssääntöösi, sivusto toimii, ja viikkoa myöhemmin se ei enää toimi. Säännössä ei muuttunut mikään. Palvelu siirtyi toiseen reunusosoitteeseen, asiakas ratkaisi toisen isäntänimen tai istunto vaihtui IPv6:een. Edessäsi oleva päätös on, onko nimeen perustuva sääntö vai eksplisiittinen vaihteluväli oikea väline tälle palvelulle, ja kolme ehtoa ratkaisee sen. Seuraava erottaa nimen osoitteesta, koska vain toinen niistä on vakaa.

Miksi yksi kysely ei ole luettelo

Sisällönjakeluverkko vastaa osoitteella, joka on valittu ratkaisijalle, alueelle ja hetkelle. Kysy kahdesti eri verkoista, niin voit saada erilaisia vastauksia. Kysy kerran ja käsittele vastausta palvelun osoiteluettelona, niin kirjoittamasi sääntö on tilannekuva eikä sääntö. Siinä on koko ongelma, kun DNS-vastausta käsitellään konfiguraationa.

On toinen aukko. Yksi näkyvä isäntänimi kattaa harvoin koko sovelluksen, koska kirjautuminen, media ja API-liikenne käyttävät usein erillisiä nimiä. Osoiterivin isäntänimestä rakennettu sääntö voi kattaa sivun ja ohittaa videon, mikä luetaan osittaiseksi epäonnistumiseksi eikä reititysvirheeksi.

Kolmas aukko on osoiteperhe. Vain v4:lle tarkoitettu sääntö ei kerro mitään AAAA-tietueesta, jota asiakas voi suosia.

Kolme ehtoa, jotka ratkaisevat verkkotunnussäännön tai vaihteluvälit

Ensinnäkin, julkaiseeko palvelu vakaan etuliitejoukon, jonka voit omistaa ja dokumentoida? Jos kyllä, eksplisiittiset vaihteluvälit ovat rehellisiä ja halpoja. Jos ei, verkkotunnussääntö on ainoa mekanismi, joka voi seurata palvelua.

Toiseksi, päivittyykö asiakkaasi verkkotunnusmekanismi? Sääntö, joka ratkeaa kerran yhteyden muodostuksessa eikä koskaan sen jälkeen, on tilannekuva paremmalla brändäyksellä. Kolmanneksi, kattaako mekanismi aliverkkotunnukset ja molemmat osoiteperheet vai vain kirjoittamasi nimet?

Vastaa noihin kolmeen, niin valinta on yleensä ilmeinen. Arvaaminen tuottaa säännön, joka toimii testissä ja pettää tuotannossa.

Testaa istuntoa, älä sivua

Lataa sivu ja tee sitten se toiminto, jolla on merkitystä: kirjaudu sisään, aloita toisto, lataa tiedosto. Jokainen niistä voi tavoittaa eri isännän, ja se, joka epäonnistuu, on se, jonka sääntösi ohitti.

Listaa, mihin istunto todella ottaa yhteyttä, sen sijaan mitä sivu näyttää:

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

Pidä ratkaisija näkyvissä vertailun ajan, sillä sääntö, joka toimii yhdestä ratkaisijasta ja epäonnistuu toisesta, kertoo sinulle CDN:n vastauksesta, ei tunnelista. Lyhyt TTL tarkoittaa myös, että tallentamallasi vastauksella on säilyvyysaika.

Mitä kukin mekanismi todella kattaa

Kaksi mekanismia näyttävät asetussivulla vaihdettavilta ja käyttäytyvät pinnan alla eri tavoin.

Ytimen osoitereitti sovittaa etuliitteitä. Sillä ei ole aavistustakaan, mikä isäntänimi on, joten se ei voi seurata palvelua, joka vaihtaa osoitteita. Verkkotunnussääntö ratkaisee nimet ja reitittää tuloksen; se seuraa palvelua mutta riippuu ratkaisijasta, päivityskäyttäytymisestä ja asiakkaan tavasta käsitellä aliverkkotunnuksia, joten nimiä seuraava sääntö on testattava ratkaisijalla, jota asiakas todella käyttää.

Kumpikaan ei ole toisen ylijoukko, minkä vuoksi niiden sekoittaminen ilman merkintää aiheuttaa myöhemmin sekaannusta.

Tarkista uudelleen, kun palvelu muuttuu

Kun asiakas on päivitetty tai palvelu muuttunut, aja sama istuntotesti uudelleen. Aiemmin toiminut osoiteluettelo on todiste siitä kaudesta, ei palvelun infrastruktuurin pysyvä luettelo.

Kirjoita muistiin, mikä mekanismi kattaa minkä isäntänimen, ja viimeisimmän tarkistuksen päivämäärä.

Se merkintä on ero sellaisen säännön, jota voit puolustaa, ja sellaisen säännön välillä, jota kukaan ei uskalla koskea. Jos palvelu julkaisee oman etuliiteluettelonsa, käytä sitä ja mainitse päivämäärä. Jos ei, sano se, ja pidä verkkotunnussääntö päivityskäyttäytymisineen kirjattuna viereen.