Aling yugto ng VPN ang nabigo: IPsec, kontrol ng L2TP o pagpapatunay ng PPP
Hanapin ang huling yugtong nagtagumpay at ayusin lamang ang layer na iyon: IPsec, ang control channel ng L2TP, ang pagpapatunay ng PPP o ang pagbibigay ng address.
Binago mo ang password at walang gumalaw, dahil ang sira ay hindi kailanman nasa PPP. Ang L2TP/IPsec ay nag-uulat ng isang error sa koneksyon para sa limang lubos na magkaibang paghahatid, at bawat paghahatid ay may sariling pag-aayos. Magtrabaho nang pabalik: hanapin ang huling yugtong nagtagumpay at baguhin lamang ang sumusunod dito. Ang pagkakasunod-sunod sa ibaba ay nagtatakda rin kung aling ebidensiya ang unang kokolektahin.
Sagutin ang apat na tanong nang sunud-sunod
Pilitin ang bagong pagtatangka, dahil ang ilang kliyente ay patuloy na nagpapakita ng dating error hanggang sa idiskonekta at ikonekta muli ang profile. Pagkatapos sagutin ito: mayroon bang IPsec security association, lumitaw ba ang koneksyon sa kontrol ng L2TP at tawag, naabot ba ng PPP ang hatol ng pagpapatunay, at binigyan ba ng IPCP ng address ang kliyente? Ang unang hindi ang yugtong inaayos mo. Lahat ng sumusunod ay hindi pa nasubok, kaya ang tinanggihang username ay walang pinatutunayan kapag kailanman walang association.
I-synchronize ang mga orasan sa magkabilang dulo bago ihambing. Ang pagtatangkang naglinis ng IPsec at nabigo sa PPP ay mukhang isang sira lamang kapag ang kliyente ay nagpapakita ng huling mensahe at ang log ng server ay may dating pagtatangka pa. Magbasa ayon sa timestamp, hindi ayon sa pinakamalakas na linya.
Kapag screenshot lamang ng user ang mayroon ka, umasa sa pinakamurang paghahati: maling pre-shared key at xl2tpd na hindi kailanman sumasagot ay gumagawa ng parehong teksto sa dialog ng Windows, ngunit ang isa ay nangangailangan ng secret na binago sa magkabilang dulo at ang isa ay nangangailangan ng daemon na sinimulan o firewall rule sa server mismo. Ang device sa gitna ay hindi maaaring ihulog ang panloob na 1701 pagkatapos itong balutin ng IPsec sa transport mode, kaya huwag maghanap ng path filter na wala.
Ano ang tunay na pag-aari ng bawat layer
Pinoprotektahan ng IPsec ang mga packet sa pagitan ng dalawang peer; dinadala ng L2TP ang PPP session sa loob ng protektadong path, kaya tinutukoy ng RFC 3193 ang transport mode sa halip na sariling tunnel. Sinasabi ng label ng kliyente ang L2TP, kaya ang tunnel at login ay parang isang mekanismo. Hindi: ang koneksyon sa kontrol ng L2TP ay nagpapatunay ng mga dulo ng tunnel kung saan ito pinagana ng deployment, at ang PPP ay hiwalay na nagpapatunay sa user sa CHAP, PAP o MS-CHAPv2 ayon sa patakaran ng server.
Ipinapaliwanag ng paghahating ito ang dalawang secret na patuloy na pinagkakamalan ng mga tao. Ang pre-shared key ay nagpapatunay sa mga peer ng IPsec. Ang username at password ay kumikilala sa user sa PPP. Ang muling pag-type ng shared secret ng Windows sa profile na nagpapatunay gamit ang mga certificate ay walang binabago sa yugtong nabibigo, at ang pag-edit ng PPP password ay hindi makapagbibigay ng nawawalang protektadong channel. Ang parehong pagpipigil ay nalalapat sa pagsusuri ng pagkakakilanlan: huwag isara ang pagkakakilanlan ng peer o ang validation ng certificate para makakuha ng tunnel, dahil ang kumokonekta noon ay ang path, hindi ang peer.
Ang pagpapatunay ay hindi rin ang katapusan ng PPP. Matapos tanggapin ang user, nakikipag-usap ang IPCP sa address ng kliyente at sa mga opsiyon ng DNS at WINS na handang ibigay ng server. Ang kliyente ay maaaring makapasa sa CHAP o MS-CHAPv2 at wala pa ring address, na sira sa loob ng PPP at hindi problema sa routing. Ang simpleng L2TP na walang IPsec ay nananatiling wasto at walang proteksyon, kaya ang matagumpay na koneksyon ay hindi kailanman nagpapatunay na protektado ang trapiko; tingnan kung ano ang hinihiling ng server, hindi ang label ng kliyente.
Magpasya mula sa unang nawawalang yugto
Basahin ang talahanayan ayon sa unang nawawalang item, mula kaliwa pakanan. Ang kanang kolum ang tanging gawaing sulit sa sandaling iyon; lahat ng nasa kaliwa nito ay napatunayan na, at ang muling pagsubok ay nagsusunog ng window ng pagkaantala nang walang idinagdag na impormasyon.
| 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 |
Tatlong row ang karapat-dapat bigyan ng babala. Ang row 1701 ang lugar kung saan karaniwang lumalapag ang mga kliyenteng Windows sa likod ng NAT: nakukumpleto ang association, pagkatapos walang dumarating, at ang dahilan ay encapsulation hindi masamang password. Ang row ng IPCP ang maling nababasa bilang problema sa ruta, dahil binabalot ng Windows ang nawawalang address sa error 720 at ang icon sa tray ay nagsasabi lamang na nabigo ang koneksyon; ang sirang iyon ay pagkatapos ng pagpapatunay at bago ang routing. Ang huling row ay hindi sira ng IPsec, kahit sabihin ng icon na disconnected.
Mga command na naghihiwalay sa mga layer
Sa Linux server na may strongSwan, inililista ng swanctl --list-sas ang mga naitatag na association kasama ang pagkakakilanlan ng peer, at sinasaklaw ng ipsec statusall ang mas lumang strongSwan at libreswan host. Sa ilalim, ipinapakita ng ip xfrm state ang aktwal na association ng kernel, habang pinatutunayan ng ss -lunp | grep 1701 kung saan nakatali ang xl2tpd. Patakbuhin ang xl2tpd -D sa harapan upang makita ang mga koneksyon sa kontrol at tawag, at i-on ang pppd debug sa /etc/ppp/options.xl2tpd upang makita ang iniaalok na paraan at tugon.
Kapag nagpakita ang mga log ng matagumpay na pagpapatunay, ang susunod na tanong ay kung natapos ang IPCP. Tingnan kung ang ip range sa seksyong [lns default] ng /etc/xl2tpd/xl2tpd.conf ay may libre pang address, at kung ang /etc/ppp/options.xl2tpd ay tunay na may ms-dns at ms-wins kung inaasahan ito ng kliyente. Ang naubos na pool at nawawalang opsiyon ng DNS ay magkaiba sa wire: iniiwan ng una ang kliyente na walang address at may 720, ang pangalawa ay nagbibigay ng address ngunit walang resolver, kaya nabibigo ang mga pangalan habang gumagana ang ping sa hilaw na address. Wala sa kanila ang naaayos sa muling pag-type ng password.
Sa kliyente, isinusulat ng L2TP plugin ng NetworkManager ang usapan ng pppd sa journal, kaya karaniwang hinihiwalay ng journalctl -u NetworkManager -b ang tunnel pataas, tinanggihan ang pagpapatunay mula sa walang tunnel talaga. Sa Windows, iniuulat ng Get-VpnConnection ang tunay na setting ng pagpapatunay ng profile, at pinapangalanan ng mga kaganapang RasClient sa ilalim ng Application sa Event Viewer ang nabigong bahagi. Kapag masyadong malabo ang dialog, i-on ang netsh ras set tracing * enable.
Kailangan ng capture ng isang pag-iingat. Sa IPsec transport mode, naka-encrypt ang panloob na UDP 1701, kaya ang capture sa panlabas na interface ay nagpapakita ng ESP, o UDP 4500 sa ilalim ng NAT-T, at walang L2TP. Ang kawalan ng 1701 sa capture ay inaasahan at hindi ebidensiya ng naka-block na port; tingnan kung gumagalaw ang counters ng ESP o 4500.
NAT, MTU at mga ruta: kung saan ka nililinlang ng stack
Sinisira ng NAT ang mga palagay bago pa mapatunayan ang anuman. Ang ESP ay sariling IP protocol, kaya itinatapon ito ng device na nag-translate maliban kung mag-encapsulate ang mga peer; iyon ang ibinibigay ng UDP 4500. Sa Windows server na mismo ay nasa likod ng home router o cloud NAT gateway, nabibigo ang yugto ng IPsec sa error 789 hanggang ang AssumeUDPEncapsulationContextOnSendRule ay itakda sa 2 sa ilalim ng PolicyAgent key at mag-restart ang makina, at ang sira ay nananatiling hindi makilala mula sa saradong port. Mas madali ang mga kliyente sa likod ng NAT: kapag may pampublikong address ang server, dinadala sila ng NAT-T sa UDP 4500 at hindi kasama ang halagang iyon.
Kapag nakataas na ang PPP, ginagaya ng MTU na may black hole ang patay na tunnel: dumadaan ang maliliit na packet, bumabitin ang TLS handshake o pag-load ng pahina, at maaaring nakakonekta pa rin ang kliyente. Ibaba ang MTU ng interface o higpitan ang MSS sa gateway bago sisihin ang server. Ang routing ng split tunnel ang isa pang manlilinlang; ang subnet na itinulak na may maling mask ay nag-iiwan ng malusog na tunnel at isang aplikasyong hindi maabot. Ang pribadong hostname ay nagdadagdag ng sariling hakbang: kung lumalabas ang query sa lokal na resolver, nabibigo ang pangalan bago pa masubok ang anumang ruta.
Checklist bago hawakan ang mga kredensiyal
Gawin ang listahan nang sunud-sunod at huminto sa unang item na nabibigo. Bawat hakbang ay mura, at bawat isa ay nag-aalis ng buong uri ng mga pagbabago.
- Kumpirmahin na may association sa magkabilang dulo, tinugma ayon sa pagkakakilanlan ng peer at hindi ayon sa label na konektado.
- Kumpirmahin na umaabot ang UDP 1701 sa xl2tpd; ang association na walang tawag ang sira mo.
- Basahin ang hatol ng PPP at, kung nagpatunay ito, ang resulta ng IPCP, bago ipagpalagay na mali ang password.
- Ngayon lamang muling ilagay ang kredensiyal sa format na inaasahan ng server, dahil binabago ng domain prefix ang account.
- Kung nabibigo pa rin, i-capture ang magkabilang dulo na may nakaayos na timestamp at ihambing nang yugto-yugto.
Ang paghinto sa ikalawang hakbang ay nangangahulugang problema sa path o encapsulation, at walang pag-edit ng password ang makakagalaw nito. Ang paghinto sa ikatlong hakbang ay nangangahulugang pinapangalanan na ng log ang paraan o pool ng address na aayusin. Alinman, ang susunod na pagbabago ay isa na maipagtatanggol mo, at titigil ka sa pag-ikot sa mga setting na hindi kailanman kasama.