Mikä VPN-vaihe epäonnistui: IPsec, L2TP-ohjaus vai PPP-todennus
Etsi viimeinen onnistunut vaihe ja korjaa vain se kerros: IPsec, L2TP-ohjauskanava, PPP-todennus tai osoitteen jako.
Vaihdoit salasanan eikä mikään liikahtanut, koska vika ei ollut koskaan PPP:ssä. L2TP/IPsec ilmoittaa yhden yhteysvirheen viidelle hyvin erilaiselle luovutukselle, ja jokaisella luovutuksella on oma korjauksensa. Työskentele takaperin: etsi viimeinen vaihe, joka onnistui, ja muuta vain sitä, mikä tulee sen jälkeen. Alla oleva järjestys ratkaisee myös, mitkä todisteet keräät ensin.
Vastaa neljään kysymykseen järjestyksessä
Pakota uusi yritys, koska jotkin asiakkaat näyttävät edellistä virhettä, kunnes profiili katkaistaan ja yhdistetään uudelleen. Vastaa sitten tähän: oliko IPsec-suojausliitto olemassa, ilmestyivätkö L2TP-ohjausyhteys ja puhelu, pääsikö PPP todennusratkaisuun ja antoiko IPCP asiakkaalle osoitteen? Ensimmäinen ei on vaihe, jonka korjaat. Kaikki sen jälkeen on testaamatta, joten hylätty käyttäjänimi ei todista mitään, kun liittoa ei koskaan ollut.
Synkronoi kellot molemmissa päissä ennen vertailua. Yritys, joka puhdisti IPsecin ja epäonnistui PPP:ssä, näyttää yhdeltä vialta, kun asiakas näyttää vain viimeisen viestin ja palvelimen loki pitää yhä aiempaa yritystä. Lue aikaleiman mukaan, älä kovaäänisimmän rivin mukaan.
Kun sinulla on vain käyttäjän kuvakaappaus, nojaa halvimpaan erotteluun: väärä ennalta jaettu avain ja xl2tpd, joka ei koskaan vastaa, tuottavat saman tekstin Windowsin valintaikkunassa, mutta toinen vaatii molemmissa päissä muutetun salaisuuden ja toinen käynnistetyn taustapalvelun tai palomuurisäännön itse palvelimella. Välissä oleva laite ei voi pudottaa sisempää 1701:tä, kun IPsec kuljetustilassa on kääriänyt sen, joten älä etsi polkusuodatinta, jota ei ole.
Mikä kukin kerros todella omistaa
IPsec suojaa paketit kahden vertaisen välillä; L2TP kuljettaa PPP-istunnon suojatun polun sisällä, minkä vuoksi RFC 3193 määrittää kuljetustilan oman tunnelin sijaan. Asiakkaan tarra sanoo L2TP, joten tunneli ja kirjautuminen tuntuvat yhdeltä mekanismilta. Ne eivät ole: L2TP-ohjausyhteys todentaa tunnelin päätepisteet siellä, missä käyttöönotto sen mahdollistaa, ja PPP todentaa käyttäjän erikseen CHAP:lla, PAP:lla tai MS-CHAPv2:lla palvelimen käytännön mukaan.
Tämä erottelu selittää ne kaksi salaisuutta, jotka ihmiset sekoittavat. Ennalta jaettu avain todentaa IPsec-vertaiset. Käyttäjänimi ja salasana tunnistavat käyttäjän PPP:lle. Windowsin jaetun salaisuuden uudelleen kirjoittaminen profiiliin, joka todentaa varmenteilla, ei muuta mitään epäonnistuvassa vaiheessa, eikä PPP-salasanaa muokkaamalla voi toimittaa puuttuvaa suojattua kanavaa. Sama pidättyväisyys koskee identiteettitarkistusta: älä kytke pois vertaisen identiteettiä tai varmenteen vahvistusta saadaksesi tunnelin, koska silloin yhdistyy polku, ei vertainen.
Todennuskaan ei ole PPP:n loppu. Kun käyttäjä on hyväksytty, IPCP neuvottelee asiakkaan osoitteen sekä DNS- ja WINS-asetukset, jotka palvelin on valmis antamaan. Asiakas voi läpäistä CHAP:in tai MS-CHAPv2:n ja jäädä silti ilman osoitetta, mikä on vika PPP:n sisällä eikä reititysongelma. Pelkkä L2TP ilman IPseciä pysyy kelvollisena ja suojaamattomana, joten onnistunut yhteys ei koskaan todista, että liikenne on suojattu; tarkista, mitä palvelin vaatii, älä asiakkaan tarraa.
Päätä ensimmäisen puuttuvan vaiheen perusteella
Lue taulukkoa ensimmäisen puuttuvan kohdan mukaan vasemmalta oikealle. Oikea sarake on ainoa työ, joka siinä hetkessä kannattaa; kaikki sen vasemmalla puolella on jo todistettu, ja uudelleen testaaminen polttaa katkoksen ikkunan lisäämättä tietoa.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Kolme riviä ansaitsee varoituksen. 1701-rivi on paikka, johon NAT:n takaiset Windows-asiakkaat yleensä päätyvät: liitto valmistuu, sitten mitään ei saavu, ja syy on kapselointi eikä huono salasana. IPCP-rivi on se, joka luetaan väärin reittiongelmaksi, koska Windows käärii puuttuvan osoitteen virheeseen 720 ja ilmaisinalueen kuvake sanoo vain, että yhteys epäonnistui; tämä vika on todentamisen jälkeen ja ennen reititystä. Viimeinen rivi ei ole lainkaan IPsec-vika, vaikka kuvake sanoo yhteyden katkenneen.
Komennot, jotka erottavat kerrokset
Linux-palvelimella, jossa on strongSwan, swanctl --list-sas listaa muodostetut liitot vertaisen identiteetin kanssa, ja ipsec statusall kattaa vanhemmat strongSwan- ja libreswan-isännät. Sen alla ip xfrm state näyttää ytimen todelliset liitot, kun taas ss -lunp | grep 1701 todistaa, mihin xl2tpd on sidottu. Suorita xl2tpd -D etualalla nähdäksesi ohjausyhteydet ja puhelut, ja kytke pppd-virheenjäljitys päälle tiedostossa /etc/ppp/options.xl2tpd nähdäksesi tarjotun menetelmän ja vastauksen.
Kun lokit näyttävät onnistuneen todentamisen, seuraava kysymys on, valmistuiko IPCP. Tarkista, onko tiedoston /etc/xl2tpd/xl2tpd.conf osiossa [lns default] olevassa ip range:ssä vielä vapaita osoitteita ja sisältääkö /etc/ppp/options.xl2tpd todella ms-dns ja ms-wins, jos asiakas odottaa niitä. Tyhjentynyt allas ja puuttuva DNS-asetus näyttävät johdolla erilaisilta: ensimmäinen jättää asiakkaan ilman osoitetta ja 720:n kanssa, toinen antaa osoitteen mutta ei nimipalvelinta, joten nimet epäonnistuvat, kun taas ping raakoihin osoitteisiin toimii. Kumpaakaan ei korjata syöttämällä salasana uudelleen.
Asiakkaassa NetworkManagerin L2TP-liitännäinen kirjoittaa pppd-keskustelun lokiin, joten journalctl -u NetworkManager -b erottaa yleensä tilan tunneli ylhäällä, todennus hylätty tilasta ei tunnelia lainkaan. Windowsissa Get-VpnConnection ilmoittaa profiilin todelliset todennusasetukset, ja Event Viewerin Application-kohdan RasClient-tapahtumat nimeävät epäonnistuvan komponentin. Kun valintaikkuna on liian epämääräinen, ota käyttöön netsh ras set tracing * enable.
Kaappaukset vaativat yhden varoituksen. IPsecin kuljetustilassa sisempi UDP 1701 on salattu, joten ulkoisella liitännällä tehty kaappaus näyttää ESP:n tai NAT-T:n alla UDP 4500:n eikä lainkaan L2TP:tä. Puuttuva 1701 kaappauksessa on odotettua eikä todiste suljetusta portista; seuraa, liikkuvatko ESP- tai 4500-laskurit.
NAT, MTU ja reitit: missä pino johtaa sinua harhaan
NAT rikkoo oletukset ennen kuin mitään on todennettu. ESP on oma IP-protokollansa, joten kääntävä laite hylkää sen, elleivät vertaiset kapseloi; juuri sitä UDP 4500 tarjoaa. Windows-palvelimella, joka itse on kotireitittimen tai pilven NAT-yhdyskäytävän takana, IPsec-vaihe epäonnistuu virheellä 789, kunnes AssumeUDPEncapsulationContextOnSendRule asetetaan arvoon 2 PolicyAgent-avaimen alle ja kone käynnistetään uudelleen, ja vika pysyy suljetusta portista erottamattomana. NAT:n takaiset asiakkaat ovat helpompia: kun palvelimella on julkinen osoite, NAT-T UDP 4500:n päällä kuljettaa heidät eikä se arvo ole mukana.
Kun PPP on ylhäällä, mustan aukon MTU jäljittelee kuollutta tunnelia: pienet paketit menevät läpi, TLS-kättely tai sivun lataus jumittuu, ja asiakas voi näyttää yhä yhdistetyltä. Laske liitännän MTU:ta tai kiristä MSS yhdyskäytävässä ennen kuin syytät palvelinta. Jaetun tunnelin reititys on toinen huijari; väärällä maskilla työnnetty aliverkko jättää tunnelin terveeksi ja yhden sovelluksen tavoittamattomaksi. Yksityinen isäntänimi lisää oman hyppynsä: jos kysely lähtee paikallisen nimipalvelimen kautta, nimi ei ratkea ennen kuin mitään reittiä testataan.
Tarkistuslista ennen kuin kosket tunnistetietoihin
Käy lista järjestyksessä läpi ja pysähdy ensimmäiseen epäonnistuvaan kohtaan. Jokainen askel on halpa, ja jokainen sulkee pois kokonaisen muutosten luokan.
- Vahvista, että liitto on olemassa molemmissa päissä, vertaisen identiteetillä sovitettuna eikä yhdistetty-tarralla.
- Vahvista, että UDP 1701 saavuttaa xl2tpd:n; liitto ilman puhelua on sinun vikasi.
- Lue PPP:n tuomio ja jos se todensi, IPCP:n tulos, ennen kuin oletat salasanan olevan väärä.
- Vasta nyt syötä tunnistetiedot uudelleen siinä muodossa, jota palvelin odottaa, koska toimialueen etuliite muuttaa tiliä.
- Jos se epäonnistuu yhä, kaappaa molemmat päät kohdistetuilla aikaleimoilla ja vertaa vaihe vaiheelta.
Toisessa vaiheessa pysähtyminen tarkoittaa polku- tai kapselointiongelmaa, eikä mikään salasanan muokkaus liikuta sitä. Kolmannessa vaiheessa pysähtyminen tarkoittaa, että loki jo nimeää korjattavan menetelmän tai osoitealtaan. Kummassakin tapauksessa seuraava muutos on sellainen, jonka voit perustella, ja lopetat sellaisten asetusten kiertämisen, jotka eivät koskaan olleet mukana.