VPN-päätepisteen nimi vastaan yksityisen palvelun nimi: kaksi omistajaa

Kaksi nimeä voi kuvata samaa toimipistettä ja vastata täysin erilaisiin kysymyksiin. vpn.branch.example kertoo etävertaiselle, mistä VPN-päätepiste löytyy, ja se on ratkaistava ennen kuin yhtään tunnelia on olemassa. inventory.branch.example kertoo valtuutetulle käyttäjälle, missä yksityinen sovellus sijaitsee, ja se on merkityksellinen vasta, kun tunneli on pystyssä. Toisen ylläpito ei tee toiselle mitään.

Nimeä molemmat tietueet ennen kuin aloitat kummankaan vianetsinnän

Kirjoita molemmat muistiin omistajineen. Kirjaa päätepisteelle, kuka päivittää julkisen osoitteen ja miten VPN-asiakasohjelma päivittää vastauksensa. Kirjaa palvelulle, kuka omistaa yksityisen osoitteen, mikä vyöhyke pitää tietuetta ja minkä ratkaisimien pitäisi vastata siitä.

Tämä lyhyt luettelo estää tämän alueen yleisimmän väärän diagnoosin: toimivan toimipistetunnelin uudelleenkäynnistyksen tietueen korjaamiseksi, joka elää kokonaan sen sisällä. Tunneli on palvelun nimen kuljetus, ei sen auktoriteetti.

Kun muutosta ehdotetaan, kysy kumpaa kahdesta tietueesta se koskee. Jos kukaan ei osaa vastata, muutos ei ole valmis aikataulutettavaksi.

Päätepiste on ratkaistava ennen kuin yhtään tunnelia on olemassa

Oletetaan, että toimipisteen internetyhteys saa uuden julkisen osoitteen. Päätepisteen päivittäjä julkaisee uuden osoitteen, ja etä-VPN-toteutuksen on pystyttävä lukemaan muuttunut vastaus. Minkä tahansa ratkaisimen, joka antaa tuon vastauksen, on oltava tavoitettavissa ilman tunnelia, muuten asiakasohjelma jahtaa nimeä, jonka se voi ratkaista vasta yhdistettyään siihen, mitä se ei löydä.

Kannattaa sanoa tuo käynnistysriippuvuus suoraan, sillä se syntyy helposti vahingossa, kun kaikki sisäiset ratkaisimet ovat VPN:n takana. Pidä tunnelia edeltävä polku päätepisteen hakua varten ja varmista asiakasohjelman uudelleenyhdistämiskäyttäytyminen sen sijaan, että olettaisit uuden vastauksen tulevan heti käyttöön.

Dynaamisella DNS:llä on myös rajat, joita tietueen päivitys ei voi ylittää. Tietueen päivittäminen ei avaa palomuurin porttia, luo NAT-määritystä eikä todista vertaisen henkilöllisyyttä. Julkaistu osoite, jonka portti on suljettu, antaa asiakasohjelman, joka ratkaisee oikein eikä silti voi yhdistää mihinkään.

Lopuksi käynnissä oleva asiakasohjelma voi jatkaa välimuistiin tallennetun päätepisteen käyttöä, kunnes se yhdistää uudelleen. Erottele muistiinpanoissasi julkaisu, välimuisti ja uudelleenyhdistämiskäytäntö, jotta vanhentunutta vertaina ei luulla rikkinäiseksi päivittäjäksi.

Palvelun nimi kertoo, missä sovellus sijaitsee

Oletetaan nyt, että tunneli pysyy terveenä mutta luettelopalvelin siirtyy osoitteesta 172.26.14.20 osoitteeseen 172.26.14.35. Julkinen päätepistetietue ei muutu, kun taas yksityisen palvelun tietueen on muututtava. Kyseiselle palvelulle varatun osoitteen tai staattisen määrityksen käyttö tekee tästä harvinaisempaa; valtuutettu päivityspolku hoitaa ne kerrat, joilla se on tarkoituksellista.

Tässä sekoittuu kaksi päivitysmekanismia. RFC 2136 määrittelee protokollan DNS-tietueiden lisäämiseksi ja poistamiseksi vyöhykkeellä, kun taas kaupallinen dynaamisen DNS:n tarjoaja voi tarjota täysin erilaisen HTTP-rajapinnan eri tarkoitukseen. Toisen käyttö ei tarkoita, että toinen olisi ympäristössäsi. Tarkista, minkä mekanismin vyöhykkeesi todella hyväksyy, ennen kuin kirjoitat päivittäjää sitä vasten.

Oikea yksityinen vastaus on vasta ensimmäinen ehto. Jotta etäkutsuja voi käyttää sitä, asiakasohjelma tarvitsee ratkaisimen, joka kantaa yksityistä vyöhykettä, käytännön, joka sallii kyselyt sille ratkaisimelle, ja edelleenohjauksen osoitteelle, joka palaa. Nimi, joka ratkeaa osoitteeseen, johon asiakasohjelma ei pääse, tuottaa aikakatkaisun, joka näyttää palvelinvialta.

Testaa kaksi polkua erikseen

Tarkista päätepiste tunnelin ulkopuolelta ja palvelu sen sisältä, ja pidä tulokset kahtena riippumattomana tosiasiana:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Jos ensimmäinen kysely epäonnistuu, ongelma on julkinen julkaisu tai tunnelia edeltävä ratkaisupolku, eikä mikään sisäinen muutos auta. Jos toinen palauttaa osoitteen mutta kolmas ei näytä reittiä tunnelin läpi, DNS-kerros on kunnossa ja edelleenohjauskäytäntö ei ole.

Aja pari jokaisen osoitemuutoksen jälkeen ja merkitse, mikä tietue siirtyi. Luovutus, joka sanoo vain »DNS päivitettiin», jättää seuraavan insinöörin arvaamaan, kumpi kahdesta elinkaaresta todella ajettiin.