Mikä L2TP-profiilin kerros oikeastaan hajosi

Etene pinossa alaspäin, älä asetussivun poikki: IPsec-neuvottelu, sitten L2TP-ohjaus, sitten PPP-todennus, sitten osoitteen ja DNS:n jako. Jokaisella kerroksella on oma virheilmaisunsa ja oma todennäköinen syynsä. Profiili, joka epäonnistuu käyttäjän todennuksessa, on jo läpäissyt kolme tarkistusta, joihin aiemmin aikakatkaistu profiili ei koskaan päässyt. Juuri tämä järjestys on selvitettävä ensin.

Sama protokollan nimi kätkee neljä eri keskustelua.

Nimeä kerros ennen asetusten muuttamista

IPsec-asetuksen epäonnistuminen viittaa jaettuun salaisuuteen, algoritmeihin tai vastapuolen identiteettiin. Sen jälkeen tapahtuva L2TP-ohjauksen epäonnistuminen viittaa itse tunnelikerrokseen, mikä on kapeampi ongelma. PPP-todennuksen virheet nimeävät tilin tai todennusmenetelmän. Osoite- tai DNS-virhe todennuksen jälkeen tarkoittaa, että siirto toimi ja asetusten vaihto ei.

Kirjaa asiakkaan versio, käyttöjärjestelmän versio ja operaattorin dokumentoitu asennus. Ilman näitä kolmea jokainen muutos on arvaus, joka saattaa vahingossa korjata jotain muuta.

Vertaa profiilia nykyiseen asiakkaaseen

Tallennettu profiili voi sisältää jaetun salaisuuden, todennusvalinnan tai päätepisteen, jota nykyinen asiakas ei enää hyväksy. Jotkin alustat ovat luopuneet L2TP/IPsec-tuesta kokonaan tai poistaneet sen, ja päivitetty asiakas voi hylätä vanhan IKE-käyttäytymisen ilman mitään muutosta palvelimella. Vertaa tallennettuja arvojasi operaattorin nykyisiin dokumentoituihin vaatimuksiin äläkä siihen, mikä toimi vuosi sitten. Näiden kahden asiakirjan välinen ero on yleensä paikka, jossa vastaus on.

Välimuistiin tallennettu salaisuus tai uudelleen nimetty tili ei yleensä vaadi enempää kuin tavallisen profiilipäivityksen, ja molemmat kannattaa tarkistaa ennen kuin suunnittelet mitään uudelleen. Ne ovat halpoja korjauksia, ja ne pitäisi sulkea pois ennen mitään arkkitehtonista työtä.

Vanhat valinnat eivät palaa sillä, että ne otetaan käyttöön

Validoinnin poistaminen ei korjaa luottamusketjun ongelmaa, eikä algoritmin ottaminen käyttöön vain siksi, että jokin foorumiketju mainitsee sen, todista mitään siitä, mitä palvelin hyväksyy. Heikot IKE-ehdotukset poistetaan asiakkaista yleensä hyvistä syistä, ja yhden ottaminen uudelleen käyttöön luo yhteyden, joka on huonompi kuin rikkoutunut. Heikompi tunneli ei ole korjaus, se on uusi ongelma, jolla on sama oire. Oikea kysymys on, mitä operaattori nyt tukee.

Kaiken käyttöön ottava korjaus muuttaa paljon enemmän kuin varsinainen vika ja jättää sinut kykenemättömäksi sanomaan, mikä sen korjasi.

Esitä migraatio projektina

Jos käyttöönotto ei enää tue vaadittua asiakasta, suunnittele korvaava ratkaisu operaattorin kanssa sen sijaan, että säilyttäisit dokumentoimattoman poikkeuksen. Siirrä käyttövaatimus, identiteetit, DNS-tietueet ja reitit, koska pelkkä uusi kättely ei luo uudelleen yhtäkään noista käyttöoikeuksista. Ne ovat ne osat, joihin toimiva yhteys hiljaa nojasi. Pidä vanha profiili turvassa, kunnes palautuminen on vahvistettu, ja poista sitten vanhentuneet tunnistetiedot sieltä, missä niitä todella hallitaan. Niiden jättäminen paikalleen on se tapa, jolla vanha reitti pysyy käyttökelpoisena kauan sen jälkeen, kun kaikki uskovat sen suljetun.

Migraatio on myös hetki kirjoittaa muistiin, mitä varten profiili oli. Muuten seuraava henkilö perii toimivan yhteyden ilman mitään selitystä.

Tarkista kerros, asiakkaan versio ja operaattorin nykyiset vaatimukset. Päätä sitten, onko kyse korjauksesta vai korvaamisesta.