Miksi PPTP ja L2TP/IPsec pysähtyvät ennen käyttäjätunnuksen kysymistä?
Käyttäjätunnuskyselyn puuttuminen tarkoittaa, ettei PPP koskaan käynnistynyt, joten vika on siirrossa, avainten vaihdossa tai tunnelin pystytyksessä. Tarkista vaiheiden järjestys ennen uudelleenasennusta.
Käyttäjätunnuskyselyn puuttuminen on diagnostinen lahja: PPP ei ole vielä käynnistynyt, joten tiliä, salasanaa ja toimialuekäytäntöä ei ole vielä kysytty. PPTP- tai L2TP/IPsec-yhteydessä asiakas kysyy tunnistetietoja vasta, kun tunneli on olemassa ja palvelin on aloittanut PPP-istunnon. Kaikki, mikä voi epäonnistua ennen sitä hetkeä, on siirtoa, avainten vaihtoa tai tunnelin pystytystä, mikä on paljon pienempi pinta-ala kuin „VPN on rikki”.
Puuttuva kysely rajaa vian kolmeen vaiheeseen
Kirjoita muistiin viimeinen vaihe, joka näkyvästi onnistui, koska jokaisella on eri omistaja ja eri korjaus. Tilin asetusten arvaileminen, kun olet jumissa kaksi vaihetta aiemmin, on tapa, jolla yksi iltapäivä katoaa.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
Asiakas, joka aikakatkaistaan ilman kyselyä, ei koskaan saanut IPsec-yhdistystä, joten vika on IKE:ssä tai siinä, pääsevätkö pakettisi ylipäätään yhdyskäytävälle. Se, joka ilmoittaa tarkistavansa tunnistetietoja ja sitten putoaa, pääsi pidemmälle kuin viesti antaa ymmärtää. Kysely, jota seuraa hylkäys, on PPP-todennus, ja se kuuluu tiliartikkeliin, ei tähän.
Vaihe yksi: protokolla, jonka palomuuri pudottaa hiljaa
PPTP tarvitsee TCP 1723:n ohjauskanavalleen ja IP-protokolla 47:n datapolulle, ja ne kulkevat erikseen. Monet verkot välittävät 1723:n ja pudottavat protokolla 47:n, mikä tuottaa tunnelin, joka neuvottelee ja sen jälkeen ei kuljeta yhtään mitään. NAT:ia tekevä reititin tarvitsee myös GRE-tuetun läpiviennin, ja vain IPv6:ta käyttävä yhteydenottopolku ei voi kuljettaa PPTP:tä missään kokoonpanossa.
L2TP IPsecin yli kuluttaa portin 500 IKE:lle ja portin 4500 NAT:n ohitukselle, käärii sitten itse L2TP-liikenteen porttiin 1701, kun taas ESP kuljettaa suojatun hyötykuorman, kun yhdistys on olemassa. Salli kaksi ohjausporttia mutta älä ESP:tä, niin saat täsmälleen otsikon oireen: näkyvää edistymistä ja sitten kuollut asiakas ennen mitään tunnistetietodialogia. Testaaminen puhelimen hotspotista on halpa tapa erottaa asiakasongelma polkuongelmasta.
Vaihe kaksi: avain, joka ei ole avain, ehdotus, jota ei tarjota
Yhteensopimaton ennalta jaettu avain epäonnistuu nopeasti ja hiljaa, ja tavallinen versio on avain, joka näyttää ruudulla oikealta mutta kantaa liitetyn rivinvaihdon tai loppuun jääneen välilyönnin. Linux-asiakkaassa dialogi ei välttämättä ole totuuden lähde: NetworkManagerin L2TP-laajennus pitää salaisuudet tiedostoissa /etc/ipsec.d/-hakemiston alla, ja vanhempi yhteyttä kohti oleva tiedosto, jonka /etc/ipsec.secrets yhä sisällyttää, otetaan käyttöön juuri kirjoittamasi sijasta. Kopioi se tiedosto turvalliseen paikkaan, poista se sisällytyspolulta ja kirjoita avain sitten käsin uudelleen.
Tämän vaiheen toinen puoli on ehdotus. Molempien päiden on sovittava samasta vaiheen 1 algoritmijoukosta — salaus, eheys ja Diffie-Hellman-ryhmä — ja vaiheen 2 vastaavista ESP-muunnoksista, tai yhdistys ei muodostu lainkaan. Yhdyskäytävä, joka tarjoaa vain 3DES:n, SHA1:n ja MODP1024:n, hylkää vahvempiin algoritmeihin asetetun asiakkaan, ja sen loki nimeää hylätyn muunnoksen. Loki nimeää ristiriidan, jos luet sitä sen sijaan että käynnistäisit palvelun taas uudelleen. Sen sijaan että kopioit algoritmijonon foorumiketjusta, kysy yhdyskäytävältä, mitkä muunnokset se todella neuvottelee: sen osoitteeseen suunnattu ike-scan palauttaa muunnokset, jotka se neuvottelee. Jos ainoa tarjous on salausta, jota käytäntösi ei enää salli, korjaus kuuluu yhdyskäytävälle, ei asiakkaan heikentämiselle.
Windowsissa avain ja todennusmenetelmä asuvat VPN-profiilissa, ja ristiriita ilmenee ennen tunnistetietokyselyä eikä sen jälkeen. Kun vastaanottaja on Windows Server, varmista, että etäkäyttörooli on asennettu, että varmenne vastaa nimeä, johon asiakkaat yhdistävät, ja ettei mikään porttisuodatin ole kapeampi kuin yllä mainitut protokollat.
Vaihe kolme: tunneli on olemassa eikä PPP käynnisty
Kun IKE valmistuu ja kyselyä ei silti koskaan ilmesty, katso tunnelidaemonia palomuurin sijaan. L2TP tarvitsee jotain, mikä kuuntelee UDP 1701:ssä — xl2tpd tai kl2tpd Linuxissa, etäkäyttöpalvelu Windowsissa — ja asennettu mutta pysäytetty palvelu näyttää asiakkaan puolelta täsmälleen samalta kuin pudotettu paketti. Tarkista kuuntelija ennen kuin avaat uudelleen jo vahvistamiasi sääntöjä. Sitten PPP:n on neuvoteltava, ja ensimmäinen LCP-vaihto on paikka, johon hiljainen epäonnistuminen yleensä laskeutuu.
Yksi tämän vaiheen ansa ei ole lainkaan verkkovika: Windows sallii vain yhden tietyn VPN-tyypin yhteyden kerrallaan, joten toinen yritys palauttaa virheen 937, „toinen tämän tyyppinen yhteys on käytössä”. Se on paikallinen sääntö, ja sen kiertää toisella laitteella, toisella tunnelityypillä tai jakamalla ainoa jo olemassa oleva yhteys.
Lue loki vaiheiden järjestyksessä sen sijaan että arvaisit
Pysäytä asiakas, käynnistä se uudelleen ja lue komponentit siinä järjestyksessä kuin ne kirjoittavat lokia. Eli ensin IPsec-daemon — strongSwan tai Libreswan, ja ipsec --version kertoo kumpi — sitten L2TP-daemon, sitten pppd. Mikä tahansa komponentti kirjoitti viimeisenä ennen vikaa, se merkitsee tutkittavan vaiheen, koska mikään sen jälkeen järjestyksessä tuleva ei ajanut lainkaan.
Vahvista tuoreella yhteydellä äläkä tallennetulla istunnolla, koska välimuistista uudelleen yhdistävä asiakas voi ohittaa vaihdon osia ja toistaa vanhentuneen tuloksen. Vahvista tavoitettavuus, avainten vaihto, tunneli ja PPP yksi kerrallaan, siinä järjestyksessä. Silloin puuttuva kysely lakkaa olemasta mysteeri ja muuttuu listan toiseksi riviksi, jonka voit todella käydä läpi. Se lista on myös se, minkä annat verkkojoukkueelle, jolta muuten pyydettäisiin palomuurin tarkistamista vian vuoksi, joka asuu käynnistymättömässä daemonissa.