Kāpēc PPTP un L2TP/IPsec apstājas pirms lietotājvārda pieprasījuma?
Ja lietotājvārda pieprasījuma nav, PPP nekad nav sācies, tāpēc kļūda ir pārnēsāšanā, atslēgu apmaiņā vai tuneļa iestatīšanā. Pirms pārinstalēšanas pārbaudiet posmu secību.
Lietotājvārda pieprasījuma neesamība ir diagnostiska dāvana: PPP vēl nav sācies, tāpēc konts, parole un domēna politika vēl nav vaicāti. PPTP vai L2TP/IPsec savienojumā klients pieprasa akreditācijas datus tikai tad, kad tunelis pastāv un serveris ir sācis PPP sesiju. Viss, kas var neizdoties pirms šī brīža, ir pārnēsāšana, atslēgu apmaiņa vai tuneļa iestatīšana, kas ir daudz mazāka joma nekā „VPN ir salūzis”.
Trūkstošais pieprasījums sašaurina kļūdu līdz trim posmiem
Pierakstiet pēdējo posmu, kas redzami izdevās, jo katram ir cits īpašnieks un cits risinājums. Minēt konta iestatījumus, kamēr esat iesprūdis divus posmus agrāk, ir veids, kā pazūd pēcpusdiena.
| 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 |
Klients, kas beidzas bez pieprasījuma, nekad nav saņēmis IPsec asociāciju, tāpēc kļūda ir IKE vai tajā, vai jūsu paketes vispār sasniedz vārteju. Tas, kas ziņo par akreditācijas datu pārbaudi un pēc tam nokrīt, ir ticis tālāk, nekā liek domāt ziņojums. Pieprasījums, kam seko atteikums, ir PPP autentifikācija, un tā pieder rakstam par kontu, nevis šim.
Pirmais posms: protokols, ko ugunsmūris klusi nomet
PPTP vajag TCP 1723 vadības kanālam un IP protokolu 47 datu ceļam, un abi ceļo atsevišķi. Daudzi tīkli pārlaiž 1723 un nomet protokolu 47, tāpēc rodas tunelis, kas vienojas un pēc tam nenes neko. Maršrutētājam ar NAT vajag arī GRE atbalstošu pārlaišanu, un piekļuves ceļš tikai ar IPv6 nevienā konfigurācijā nevar pārnēsāt PPTP.
L2TP virs IPsec iztērē portu 500 IKE un portu 4500 NAT šķērsošanai, pēc tam iesaiņo pašu L2TP datplūsmu 1701, bet ESP pārnēsā aizsargāto kravu, tiklīdz asociācija pastāv. Atļaujiet divus vadības portus, bet ne ESP, un jūs iegūsiet tieši virsraksta simptomu: redzams progress, pēc tam miris klients pirms jebkura akreditācijas datu dialoga. Testēšana no tālruņa hotspota ir lēts veids, kā atdalīt klienta problēmu no ceļa problēmas.
Otrais posms: atslēga, kas nav atslēga, priekšlikums, kas netiek piedāvāts
Nesakrītoša iepriekš koplietota atslēga neizdodas ātri un klusi, un parastā versija ir atslēga, kas ekrānā izskatās pareizi, bet satur ielīmētu rindas pārtraukumu vai atstarpi beigās. Linux klientā dialogs ne vienmēr ir patiesības avots: NetworkManager L2TP spraudnis glabā noslēpumus failos zem /etc/ipsec.d/, un vecāks fails par savienojumu, ko /etc/ipsec.secrets joprojām iekļauj, tiks izmantots tā vietā, kuru tikko ierakstījāt. Nokopējiet šo failu drošā vietā, izņemiet to no iekļaušanas ceļa un pēc tam ierakstiet atslēgu vēlreiz ar roku.
Otra šī posma puse ir priekšlikums. Abām pusēm jāvienojas par vienu un to pašu fāzes 1 algoritmu kopu — šifrēšanu, integritāti un Diffie-Hellman grupu — un par atbilstošām ESP transformācijām fāzei 2, citādi asociācija vispār neveidojas. Vārteja, kas piedāvā tikai 3DES, SHA1 un MODP1024, atteiks klientu, kas konfigurēts stiprākiem algoritmiem, un tās žurnāls nosauc atteikto transformāciju. Žurnāls nosauc neatbilstību, ja to lasāt, nevis vēlreiz restartējat pakalpojumu. Tā vietā, lai kopētu algoritmu virkni no foruma pavediena, pajautājiet vārtejai, par kādām transformācijām tā patiešām vienosies: uz tās adresi vērsts ike-scan atgriež transformācijas, par kurām tā vienosies. Ja vienīgais piedāvājums ir kriptogrāfija, ko jūsu politika vairs nepieļauj, labojums pieder vārtejai, nevis klienta pazemināšanai.
Operētājsistēmā Windows atslēga un autentifikācijas metode dzīvo VPN profilā, un neatbilstība parādās pirms akreditācijas datu pieprasījuma, nevis pēc tam. Kur saņēmējs ir Windows Server, pārliecinieties, ka ir instalēta attālinātās piekļuves loma, ka sertifikāts atbilst nosaukumam, ar ko savienojas klienti, un ka neviens portu filtrs nav šaurāks par iepriekš minētajiem protokoliem.
Trešais posms: tunelis pastāv, bet PPP nesākas
Kad IKE ir pabeigts un pieprasījums tomēr neparādās, skatieties uz tuneļa dēmonu, nevis uz ugunsmūri. L2TP vajag kaut ko, kas klausās UDP 1701 — xl2tpd vai kl2tpd Linux, attālinātās piekļuves pakalpojums Windows — un instalēts, bet apturēts pakalpojums no klienta puses izskatās tieši tāpat kā nomests pakets. Pārbaudiet klausītāju, pirms atkal atverat jau pārbaudītos noteikumus. Tad PPP ir jāvienojas, un pirmā LCP apmaiņa ir vieta, kur parasti nolaižas klusa neveiksme.
Viens slazds šajā posmā nemaz nav tīkla kļūda: Windows atļauj tikai vienu noteikta veida VPN savienojumu vienlaikus, tāpēc otrs mēģinājums atgriež kļūdu 937, „cits šāda veida savienojums jau tiek lietots”. Tas ir vietējs noteikums, un apiešanas ceļš ir cita ierīce, cits tuneļa veids vai vienīgā jau esošā savienojuma koplietošana.
Lasiet žurnālu posmu secībā, nevis miniet
Apturiet klientu, palaidiet to vēlreiz un lasiet komponentus tādā secībā, kādā tie raksta žurnālu. Tas nozīmē vispirms IPsec dēmons — strongSwan vai Libreswan, un ipsec --version pasaka, kurš — tad L2TP dēmons, tad pppd. Kurš komponents rakstīja pēdējais pirms neveiksmes, tas iezīmē posmu, kas jāizmeklē, jo viss, kas secībā nāk pēc tam, nemaz nedarbojās.
Pārbaudiet ar jaunu savienojumu, nevis saglabātu sesiju, jo klients, kas atkārtoti pievienojas no kešatmiņas, var izlaist apmaiņas daļas un atveidot novecojušu rezultātu. Apstipriniet sasniedzamību, atslēgu apmaiņu, tuneli un PPP pa vienam, tādā secībā. Tad trūkstošais pieprasījums pārstāj būt noslēpums un kļūst par saraksta otro rindu, ar ko patiešām var strādāt. Šis saraksts ir arī tas, ko nododat tīkla komandai, kurai citādi prasītu pārbaudīt ugunsmūri kļūdas dēļ, kas mīt nepalaižamā dēmonā.