Waarom stop PPTP en L2TP/IPsec voordat om die gebruikersnaam gevra word?

Geen gebruikersnaamversoek is 'n diagnostiese geskenk: PPP het nog nie begin nie, so die rekening, die wagwoord en die domeinbeleid is nog nie geraadpleeg nie. In 'n PPTP- of L2TP/IPsec-verbinding vra die kliënt eers om geloofsbriewe nadat die tonnel bestaan en die bediener 'n PPP-sessie begin het. Alles wat voor daardie oomblik kan misluk, is vervoer, sleuteluitruiling of tonnelopstelling, wat 'n veel kleiner oppervlak is as „die VPN is stukkend”.

Ontbrekende versoek vernou die fout tot drie fases

Skryf die laaste fase neer wat sigbaar geslaag het, want elkeen het 'n ander eienaar en 'n ander oplossing. Om aan die rekeninginstellings te raai terwyl u twee fases vroeër vasgehaak is, is hoe 'n middag verdwyn.

'n Kliënt wat uittyd sonder enige versoek het nooit 'n IPsec-assosiasie gekry nie, so die fout lê in IKE of daarin of u pakkette die poort ooit bereik. Een wat sê dat dit geloofsbriewe verifieer en dan val, het verder gekom as wat die boodskap laat blyk. 'n Versoek wat deur 'n weiering gevolg word, is PPP-verifikasie, en dit hoort in 'n rekeningartikel eerder as in hierdie een.

Fase een: die protokol wat 'n vuurmuur stilweg laat val

PPTP benodig TCP 1723 vir sy beheerkanaal en IP-protokol 47 vir die datapad, en die twee reis apart. Baie netwerke stuur 1723 deur en laat protokol 47 val, wat 'n tonnel lewer wat onderhandel en dan glad niks dra nie. 'n Roeteerder wat NAT doen, het ook 'n GRE-vermoënde deurlaat nodig, en 'n slegs-IPv6-toegangspad kan PPTP onder geen opset dra nie.

L2TP oor IPsec gebruik poort 500 vir IKE en poort 4500 vir NAT-traversering, en verpak dan die L2TP-verkeer self in 1701, terwyl ESP die beskermde vrag dra sodra die assosiasie bestaan. Laat die twee beheerpoorte toe maar nie ESP nie, en u kry presies die simptoom in die titel: sigbare vordering, dan 'n dooie kliënt voordat enige geloofsbriefdialoog verskyn. Toets vanaf 'n selfoon se hotspot is 'n goedkoop manier om 'n kliëntprobleem van 'n padprobleem te skei.

Fase twee: 'n sleutel wat nie die sleutel is nie, 'n voorstel wat nie aangebied word nie

'n Sleutel wat nie ooreenstem nie, misluk vinnig en stil, en die gewone weergawe is 'n sleutel wat op die skerm korrek lyk maar 'n geplakte reëlbreuk of 'n sleepspasie dra. Op 'n Linux-kliënt is die dialoog nie noodwendig die bron van waarheid nie: die NetworkManager-L2TP-inprop hou geheime in lêers onder /etc/ipsec.d/, en 'n ouer per-verbinding-lêer wat /etc/ipsec.secrets steeds insluit, sal gebruik word in plaas van die een wat u pas getik het. Kopieer daardie lêer na 'n veilige plek, haal dit uit die insluitpad en tik dan die sleutel met die hand oor.

Die ander helfte van hierdie fase is die voorstel. Albei kante moet op dieselfde fase 1-algoritmeset besluit — enkripsie, integriteit en Diffie-Hellman-groep — en op passende ESP-transformasies vir fase 2, anders vorm die assosiasie glad nie. 'n Poort wat slegs 3DES, SHA1 en MODP1024 aanbied, sal 'n kliënt weier wat vir sterker algoritmes opgestel is, en sy log noem die geweierde transformasie. Die log noem die wanverhouding as u dit lees in plaas daarvan om die diens weer te herbegin. In plaas daarvan om 'n algoritmereeks uit 'n forumdraad te kopieer, vra die poort watter transformasies dit werklik sal onderhandel: ike-scan wat na sy adres gerig word, gee die transformasies terug wat dit sal onderhandel. As die enigste aanbod kriptografie is wat u beleid nie meer toelaat nie, hoort die oplossing by die poort, nie by 'n afgradering van die kliënt nie.

Op Windows woon die sleutel en die verifikasiemetode in die VPN-profiel, en 'n wanverhouding duik voor die geloofsbriefversoek op eerder as daarna. Waar die ontvanger 'n Windows Server is, bevestig dat die remote access-rol geïnstalleer is, dat die sertifikaat ooreenstem met die naam waarmee kliënte verbind, en dat geen poortfilter smaller is as die protokolle hierbo nie.

Fase drie: die tonnel bestaan en PPP begin nooit nie

Wanneer IKE voltooi en die versoek steeds nooit verskyn nie, kyk na die tonneldemon eerder as na die vuurmuur. L2TP benodig iets wat op UDP 1701 luister — xl2tpd of kl2tpd op Linux, die remote access-diens op Windows — en 'n diens wat geïnstalleer maar gestop is, lyk van die kliënt se kant soos 'n weggevalle pakket. Kontroleer die luisteraar voordat u reëls heropen wat u reeds geverifieer het. PPP moet dan onderhandel, en die eerste LCP-uitruiling is waar 'n stille mislukking gewoonlik beland.

Een strik in hierdie fase is glad nie 'n netwerkfout nie: Windows laat slegs een verbinding van 'n gegewe VPN-tipe op 'n slag toe, so 'n tweede poging gee fout 937, „'n ander verbinding van hierdie tipe is in gebruik”. Dit is 'n plaaslike reël, en die manier daaromheen is 'n ander toestel, 'n ander tonneltipe, of om die een verbinding te deel wat reeds bestaan.

Lees die log in fasevolgorde in plaas daarvan om te raai

Stop die kliënt, begin dit weer, en lees die komponente in die volgorde waarin hulle log. Dit beteken eerste die IPsec-demon — strongSwan of Libreswan, en ipsec --version sê vir u watter een — dan die L2TP-demon, dan pppd. Watter komponent ook al laas geskryf het voor die mislukking, merk die fase om te ondersoek, want enigiets wat daarna in die volgorde kom, het glad nie gehardloop nie.

Verifieer met 'n vars verbinding eerder as 'n gestoorde sessie, want 'n kliënt wat uit die kas herverbind, kan dele van die uitruiling oorslaan en 'n verouderde resultaat reproduceer. Bevestig bereik, sleuteluitruiling, tonnel en PPP een op 'n slag, in daardie volgorde. Die ontbrekende versoek hou dan op om 'n raaisel te wees en word die tweede reël van 'n lys wat u werklik kan deurwerk. Daardie lys is ook wat u aan die netwerkspan gee, wat anders gevra sal word om die vuurmuur na te gaan vir 'n fout wat in 'n ongestarte demon woon.