Kial PPTP kaj L2TP/IPsec haltas antaŭ la demando pri uzantnomo?

Mankanta demando pri uzantnomo estas diagnoza donaco: PPP ankoraŭ ne ekfunkciis, do la konto, la pasvorto kaj la domajna politiko ankoraŭ ne estis konsultitaj. En PPTP- aŭ L2TP/IPsec-konekto la kliento petas legitimilojn nur post kiam la tunelo ekzistas kaj la servilo komencis PPP-sesion. Ĉio, kio povas malsukcesi antaŭ tiu momento, estas transporto, ŝlosilinterŝanĝo aŭ tunela starigo, kio estas multe pli malgranda areo ol „la VPN estas difektita”.

Mankanta demando mallarĝigas la difekton al tri etapoj

Notu la lastan etapon, kiu videble sukcesis, ĉar ĉiu havas alian posedanton kaj alian riparon. Diveni la kontajn agordojn dum vi estas blokita du etapojn pli frue estas kiel posttagmezo malaperas.

Kliento, kiu finiĝas pro tempolimo sen demando, neniam ricevis IPsec-asocion, do la difekto estas en IKE aŭ en tio, ĉu viaj pakoj entute atingas la enirejon. Tiu, kiu raportas, ke ĝi kontrolas legitimilojn, kaj poste falas, iris pli malproksimen ol la mesaĝo sugestas. Demando sekvata de malakcepto estas PPP-aŭtentigo, kaj tio apartenas al konto-artikolo, ne al ĉi tiu.

Etapo unu: la protokolo, kiun fajroŝirmilo silente forĵetas

PPTP bezonas TCP 1723 por sia rega kanalo kaj IP-protokolon 47 por la datenvojo, kaj la du vojaĝas aparte. Multaj retoj plusendas 1723 kaj forĵetas protokolon 47, kio produktas tunnelon, kiu interkonsentas kaj poste portas absolute nenion. Enkursigilo faranta NAT ankaŭ bezonas trairon kun GRE-subteno, kaj alirvojo nur per IPv6 ne povas porti PPTP sub neniu agordo.

L2TP super IPsec elspezas pordon 500 por IKE kaj pordon 4500 por NAT-trapaso, poste envolvas la L2TP-trafikon mem en 1701, dum ESP portas la protektitan ŝarĝon post kiam la asocio ekzistas. Permesu la du regajn pordojn sed ne ESP, kaj vi ricevos ĝuste la simptomon el la titolo: videbla progreso, poste morta kliento antaŭ ajna legitimila dialogo. Testi de poŝtelefona hotspoto estas malmultekosta maniero apartigi klientan problemon de voja problemo.

Etapo du: ŝlosilo, kiu ne estas la ŝlosilo, propono, kiu ne estas ofertata

Neakorda antaŭe kunhava ŝlosilo malsukcesas rapide kaj silente, kaj la kutima versio estas ŝlosilo, kiu aspektas ĝusta sur la ekrano dum ĝi portas algluitan linisalton aŭ spacon ĉe la fino. Sur Linux-kliento la dialogo ne nepre estas la fonto de vero: la L2TP-kromprogramo de NetworkManager tenas sekretojn en dosieroj sub /etc/ipsec.d/, kaj pli malnova dosiero por unuopa konekto, kiun /etc/ipsec.secrets ankoraŭ inkluzivas, estos uzata anstataŭ tiu, kiun vi ĵus tajpis. Kopiu tiun dosieron al sekura loko, forigu ĝin el la inkluziva vojo, kaj poste retajpu la ŝlosilon permane.

La alia duono de ĉi tiu etapo estas la propono. Ambaŭ finoj devas interkonsenti pri la sama fazo 1-algoritmara aro — ĉifrado, integreco kaj Diffie-Hellman-grupo — kaj pri kongruaj ESP-transformoj por fazo 2, alie la asocio tute ne formiĝas. Enirejo, kiu ofertas nur 3DES, SHA1 kaj MODP1024, rifuzos klienton agorditan por pli fortaj algoritmoj, kaj ĝia protokolo nomas la rifuzitan transformon. La protokolo nomas la malkongruon se vi legas ĝin anstataŭ rekomencigi la servon denove. Anstataŭ kopii algoritman ĉenon el forumo, demandu la enirejon, kiujn transformojn ĝi vere interkonsentos: ike-scan direktita al ĝia adreso redonas la transformojn, kiujn ĝi interkonsentos. Se la sola oferto estas kriptografio, kiun via politiko jam ne permesas, la ripareto apartenas al la enirejo, ne al malaltigo de la kliento.

En Windows la ŝlosilo kaj la aŭtentiga metodo loĝas en la VPN-profilo, kaj malkongruo aperas antaŭ la legitimila demando, ne post ĝi. Kie la ricevanto estas Windows Server, konfirmu, ke la fora alira rolo estas instalita, ke la atestilo kongruas kun la nomo, al kiu klientoj konektiĝas, kaj ke neniu porda filtrilo estas pli mallarĝa ol la supraj protokoloj.

Etapo tri: la tunelo ekzistas kaj PPP neniam ekfunkcias

Kiam IKE finiĝis kaj la demando tamen neniam aperas, rigardu la tunelan demonon anstataŭ la fajroŝirmilon. L2TP bezonas ion, kio aŭskultas sur UDP 1701 — xl2tpd aŭ kl2tpd en Linux, la fora alira servo en Windows — kaj instalita sed haltigita servo aspektas de la klienta flanko same kiel forĵetita pako. Kontrolu la aŭskultanton antaŭ ol remalfermi regulojn, kiujn vi jam konfirmis. Poste PPP devas interkonsenti, kaj la unua LCP-interŝanĝo estas kie silenta malsukceso kutime surteriĝas.

Unu kaptilo en ĉi tiu etapo tute ne estas reta difekto: Windows permesas nur unu konekton de difinita VPN-tipo samtempe, do dua provo redonas eraron 937, „alia konekto de ĉi tiu tipo estas uzata”. Tio estas loka regulo, kaj la vojo preter ĝi estas alia aparato, alia tunela tipo aŭ kunhavigo de la ununura konekto, kiu jam ekzistas.

Legu la protokolon laŭ etapa ordo anstataŭ diveni

Haltigu la klienton, restartigu ĝin, kaj legu la komponentojn laŭ la ordo, en kiu ili skribas protokolon. Tio signifas unue la IPsec-demonon — strongSwan aŭ Libreswan, kaj ipsec --version diras al vi kiun — poste la L2TP-demonon, poste pppd. Kiu ajn komponento skribis laste antaŭ la malsukceso, ĝi markas la etapon por esploro, ĉar ĉio, kio venas post ĝi en la sinsekvo, tute ne funkciis.

Kontrolu per freŝa konekto anstataŭ per konservita sesio, ĉar kliento, kiu rekonektiĝas el la kaŝmemoro, povas preterpasi partojn de la interŝanĝo kaj reprodukti malnovan rezulton. Konfirmu atingeblon, ŝlosilinterŝanĝon, tunnelon kaj PPP unu post la alia, en tiu ordo. Tiam la mankanta demando ĉesas esti mistero kaj fariĝas la dua linio de listo, kiun vi povas efektive trakribri. Tiu listo estas ankaŭ tio, kion vi transdonas al la reta teamo, kiun alie oni petus kontroli la fajroŝirmilon pro difekto, kiu loĝas en neŝaltita demono.