L2TP/IPsec epäonnistuu: erottele IPsec, tunnelin todennus vai PPP-kirjautuminen

Yhden L2TP/IPsec-yhteyden sisällä todentuu kolme asiaa, ja vain yksi niistä koskee soittavaa henkilöä. IPsec todistaa tunnelin päätepisteet, L2TP-ohjausyhteys voi todistaa vastapuolet uudelleen omalla salaisuudellaan, ja sen jälkeen PPP todistaa istunnon sisällä olevan käyttäjätilin. Epäonnistuminen millä tahansa vaiheella näyttää asiakasohjelman ikkunassa yleiseltä kirjautumisvirheeltä ja näyttää palvelimen lokissa täysin erilaiselta. Käy vaiheet järjestyksessä läpi ja pysähdy ensimmäiseen, joka epäonnistuu, koska jokainen testaamattoman vaiheen alapuolella oleva vaihe on myös testaamaton.

Kolme todennusvaihetta, kolme eri identiteettiä

IPsec todistaa, kenen päätepisteet ovat, käyttäen ennalta jaettua avainta tai varmennetta. Tämä identiteetti kuuluu koneille tai yhdyskäytäville, ei koskaan näppäimistön ääressä olevalle ihmiselle. Kun vastapuolet eivät pääse tässä vaiheessa sopimukseen, yhtään L2TP-pakettia ei vaihdeta.

L2TP-ohjausyhteys voi lisätä toisen, erillisen haaste-vastaus-vaihdon, jota ohjaa jaettu salaisuus, joka molemmilla päillä täytyy olla.

RFC 2661 tekee tästä ohjausyhteyden todentamisesta valinnaisen, mikä selittää, miksi sama virhe tuottaa erilaisia oireita kahdella palvelimella. Käyttöönotto, joka ei ole koskaan määrittänyt tunnelin salaisuutta, ohittaa vaiheen kokonaan; se, joka määritti sen vain toiselle puolelle, epäonnistuu ennen kuin PPP:tä edes tarjotaan. Sen jälkeen PPP todentaa käyttäjän PAP-, CHAP- tai MSCHAPv2-menetelmällä ja luovuttaa nimen tilitietovarastolle, joka voi olla paikallinen, tiedostossa chap-secrets tai RADIUS-palvelimella. Väärä salasana siinä kohdassa jättää sinut silti toimivan tunnelin ja epäonnistuneen istunnon kanssa.

Lue pysähdyskohta ennen kuin muokkaat asetusta

Aloita komennolla ipsec --version, jotta tiedät, kuuluuko tilatuloste strongSwanille vai Libreswanille. Lue sitten palvelimen loki, älä asiakasohjelman ikkunaa, koska palvelin kirjaa, mikä vaihe kieltäytyi.

Yksi rivi ratkaisee yleensä tiketin: valitus IKE:sta tai ehdotuksista on ensimmäinen vaihe, ohjausyhteyden viesti on toinen ja PPP-menetelmän tai tilin hylkäys on kolmas. Kopioi se rivi tikettiin aikaleiman kanssa. Asiakaspuolelta arvaileminen tuhlaa ainoan todisteen, joka sinulla jo on.

Pidä avainmateriaali ja salasanat poissa siltä liittämiseltä; vaiheen nimi ohjaa työn, ja vuotanut ennalta jaettu avain avaa tiketin uudelleen pahemmin seurauksin.

Ensimmäinen vaihe: onko IPsecillä assosiaatio?

Aja ipsec statusall strongSwanilla tai ipsec whack --status Libreswanilla ja etsi muodostettu ala-assosiaatio, jonka laskurit eivät ole nollia. ip xfrm state näyttää ytimen näkymän molemmissa. Asennettu SA-pari, jonka laskurit kasvavat, tarkoittaa, että ensimmäinen vaihe on valmis ja voit jatkaa.

Assosiaation täydellinen puuttuminen viittaa vastapuolen osoitteeseen, ehdotusjoukkoon tai ennalta jaettuun avaimeen ja toisinaan laitteeseen, joka kirjoittaa UDP 500 uudelleen mutta pudottaa UDP 4500. Assosiaatio, joka muodostuu ja katoaa muutaman sekunnin kuluttua, on yleensä kahden pään elinikien ero eikä tunnistetietojen ongelma. Tarkista, listaavatko molemmat puolet samat salaus- ja hajautusehdotukset, ennen kuin kirjoitat mitään uudelleen. Jos eivät, mikään avain ei tule koskaan toimimaan.

Pysähdy, kun assosiaatio puuttuu. PPP-asetusten muokkaaminen siinä kohdassa ei muuta mitään ja kätkee todellisen vian seuraavalta henkilöltä.

Toinen vaihe: todentuiko L2TP-ohjausyhteys?

Kun IPsec on pystyssä, seuraa L2TP-taustaohjelmaa ja katso, saavuttaako ohjausyhteys muodostetun tilan, koska PPP ei voi alkaa ennen sitä. Kieltäytyminen ohjausyhteydellä tarkoittaa, että tunnelin salaisuus on eri päissä, tai että toinen pää vaatii salaisuuden, jota toinen ei koskaan lähetä. Asiakasohjelmat tarjoavat usein yhden kentän, jonka nimi on jaettu salaisuus, ja se kuuluu yleensä IPsecille eikä L2TP:lle. Sen täyttäminen ei määritä tunnelin salaisuutta, eikä sen tyhjentäminen poista sitä käytöstä.

Jos kummallakaan puolella ei ole määritettyä tunnelin salaisuutta, ohita tämä vaihe ja käsittele ohjausyhteyden epäonnistumista sen sijaan tavoitettavuutena. Varmista, että UDP 1701 tavoittaa taustaohjelman ja että molemmat päät sopivat samasta kapseloinnista. Palomuurisääntö, joka on kirjoitettu jommallekummalle näistä ehdoista, on tavallinen syy yhteydelle, joka avautuu vain puoliksi.

Vain istunto, joka alkaa neuvotella PPP:tä, on todella ohittanut tunnelivaiheen.

Kolmas vaihe: hylkääkö PPP tilin?

PPP:n epäonnistuminen näyttää ulkoa erilaiselta: tunneli on muodostettu, istunto alkaa ja taustaohjelma kirjaa todennusmenetelmän epäonnistumisen tai tilin hylkäyksen. Lue menetelmä, joka siinä viestissä nimetään. PAP ja CHAP epäonnistuvat eri syistä, ja palvelin, joka hylkää toisen, hylkää asiakkaan, joka tarjoaa vain sitä.

Linux-palvelimella käy läpi asetustiedosto, jonka taustaohjelma antaa PPP:lle, tavallisesti /etc/ppp/options.xl2tpd, ja varmista, mitkä menetelmät hyväksytään ja missä tilit ratkaistaan. Nimi, joka on RADIUS-palvelimella mutta ei paikallisessa salaisuustiedostossa, epäonnistuu puhtaasti ja näyttää siltä kuin salasana olisi väärä. Tarkista sitten, että asiakas tarjoaa menetelmää, jonka palvelin hyväksyy, eikä vahvempaa, josta palvelin kieltäytyy neuvottelemasta. Ennalta jaetun avaimen vaihtaminen tämän vaiheen korjaamiseksi tuhlaa iltapäivän eikä muuta mitään.

Kun istunto lopulta nousee, osoitteiden jakaminen, DNS ja reitit ovat vielä tarkistamatta, ja jokainen niistä epäonnistuu hiljaa omalla tavallaan. Pidä kolme kerrosta erillään muistiinpanoissasi: oikea avain väärällä tilillä epäonnistuu aina, eikä yhden kerroksen korjaaminen koskaan korjaa toista.