Bakit humihinto ang PPTP at L2TP/IPsec bago ang tanong sa username?

Ang kawalan ng tanong sa username ay isang regalo sa diyagnosis: hindi pa nagsimula ang PPP, kaya hindi pa tinanong ang account, password at patakaran ng domain. Sa koneksyong PPTP o L2TP/IPsec humihingi lamang ng kredensyal ang kliyente kapag umiiral na ang tunnel at nagsimula na ang server ng sesyong PPP. Lahat ng maaaring mabigo bago ang sandaling iyon ay transport, pagpapalitan ng key o pag-setup ng tunnel, isang mas maliit na saklaw kaysa «sira ang VPN».

Ang nawawalang tanong ay nagpapaliit ng depekto sa tatlong yugto

Itala ang huling yugtong nakita na nagtagumpay, dahil bawat isa ay may ibang may-ari at ibang lunas. Ang manghula sa mga setting ng account habang natigil dalawang yugto ang nakalipas ang paraan kung paano nawawala ang isang hapon.

Ang kliyenteng nag-expire na walang tanong ay hindi kailanman nakakuha ng asosasyong IPsec, kaya ang depekto ay nasa IKE o sa kung umaabot ba ang mga packet mo sa gateway. Ang isa na nag-uulat na nagbe-verify ng kredensyal at pagkatapos ay bumabagsak ay mas malayo pa kaysa sa ipinahihiwatig ng mensahe. Ang tanong na sinusundan ng pagtanggi ay authentication ng PPP, at iyon ay para sa artikulo tungkol sa account, hindi dito.

Unang yugto: ang protocol na tahimik na itinatapon ng firewall

Kailangan ng PPTP ang TCP 1723 para sa control channel nito at IP protocol 47 para sa data path, at magkahiwalay silang naglalakbay. Maraming network ang nagpapasa ng 1723 at itinatapon ang protocol 47, na nagbubunga ng tunnel na nakikipagnegosasyon at pagkatapos ay wala namang dinadala. Ang router na gumagawa ng NAT ay kailangan din ng pass-through na sumusuporta sa GRE, at ang access path na IPv6 lamang ay hindi makakadala ng PPTP sa anumang configuration.

Ang L2TP sa ibabaw ng IPsec ay gumagamit ng port 500 para sa IKE at port 4500 para sa pagtawid sa NAT, pagkatapos ay binabalot ang mismong trapik ng L2TP sa 1701, habang dinadala ng ESP ang protektadong payload kapag umiiral na ang asosasyon. Payagan ang dalawang control port ngunit hindi ang ESP, at makukuha mo ang eksaktong sintomas sa pamagat: nakikitang pag-unlad, pagkatapos ay patay na kliyente bago ang anumang dayalogo ng kredensyal. Ang pagsubok mula sa hotspot ng telepono ay murang paraan upang ihiwalay ang problema ng kliyente sa problema ng ruta.

Ikalawang yugto: isang key na hindi ang key, isang panukalang hindi inaalok

Ang pre-shared key na hindi tumutugma ay nabigo nang mabilis at tahimik, at ang karaniwang anyo ay isang key na mukhang tama sa screen ngunit may nakadikit na line break o puwang sa dulo. Sa kliyenteng Linux hindi kinakailangang ang dayalogo ang pinagmumulan ng katotohanan: ang L2TP plugin ng NetworkManager ay nag-iimbak ng mga lihim sa mga file sa ilalim ng /etc/ipsec.d/, at ang lumang file bawat koneksyon na kasama pa rin ng /etc/ipsec.secrets ay gagamitin sa halip ng kakatype mo lang. Kopyahin ang file na iyon sa ligtas na lugar, alisin ito sa landas ng pagsasama, at pagkatapos ay i-type muli ang key nang manu-mano.

Ang kalahating bahagi ng yugtong ito ay ang panukala. Kailangang magkasundo ang dalawang dulo sa parehong set ng algorithm ng fase 1 — encryption, integridad at grupong Diffie-Hellman — at sa tumutugmang ESP transform para sa fase 2, kung hindi ay hindi mabubuo ang asosasyon. Ang gateway na nag-aalok lamang ng 3DES, SHA1 at MODP1024 ay tatanggihan ang kliyenteng naka-configure para sa mas malalakas na algorithm, at pinangalanan ng log nito ang tinanggihang transform. Pinangalanan ng log ang kakulangan ng tugma kung babasahin mo ito sa halip na i-restart muli ang serbisyo. Sa halip na kopyahin ang string ng algorithm mula sa thread ng forum, tanungin ang gateway kung aling mga transform ang talagang makikipagnegosasyon ito: ang ike-scan na nakatutok sa address nito ay nagbabalik ng mga transform na makikipagnegosasyon ito. Kung ang tanging alok ay cryptography na hindi na pinapayagan ng iyong patakaran, ang pagwawasto ay nasa gateway, hindi sa pagbaba ng antas ng kliyente.

Sa Windows ang key at paraan ng authentication ay nasa profile ng VPN, at ang kakulangan ng tugma ay lumilitaw bago ang tanong sa kredensyal at hindi pagkatapos. Kapag ang tatanggap ay Windows Server, tiyakin na naka-install ang tungkulin ng remote access, na tumutugma ang sertipiko sa pangalan kung saan kumokonekta ang mga kliyente, at na walang filter ng port na mas makitid kaysa sa mga protocol sa itaas.

Ikatlong yugto: umiiral ang tunnel at hindi nagsisimula ang PPP

Kapag natapos na ang IKE at hindi pa rin lumilitaw ang tanong, tingnan ang daemon ng tunnel at hindi ang firewall. Kailangan ng L2TP ng isang bagay na nakikinig sa UDP 1701 — xl2tpd o kl2tpd sa Linux, ang serbisyo ng remote access sa Windows — at ang serbisyong naka-install ngunit nakatigil ay mukhang eksaktong kapareho ng itinapong packet mula sa panig ng kliyente. Suriin ang tagapakinig bago muling buksan ang mga patakarang na-verify mo na. Pagkatapos ay kailangang makipagnegosasyon ang PPP, at ang unang pagpapalitan ng LCP ang lugar kung saan karaniwang lumalapag ang tahimik na kabiguan.

Ang isang bitag sa yugtong ito ay hindi talaga depekto ng network: pinapayagan ng Windows ang isang koneksyon lamang ng isang partikular na uri ng VPN sa isang pagkakataon, kaya ang ikalawang pagtatangka ay nagbabalik ng error 937, «may ibang koneksyon ng ganitong uri na ginagamit». Lokal na patakaran iyon, at ang paraan sa paligid nito ay ibang device, ibang uri ng tunnel, o pagbabahagi ng nag-iisang koneksyong umiiral na.

Basahin ang log sa pagkakasunud-sunod ng mga yugto sa halip na manghula

Itigil ang kliyente, simulan muli ito, at basahin ang mga bahagi sa pagkakasunud-sunod kung paano sila nagsusulat ng log. Ibig sabihin, una ang daemon ng IPsec — strongSwan o Libreswan, at sinasabi ng ipsec --version kung alin — pagkatapos ang daemon ng L2TP, pagkatapos ang pppd. Alinmang bahagi ang huling nagsulat bago ang kabiguan ang nagmamarka ng yugtong dapat imbestigahan, dahil wala sa mga sumusunod dito sa pagkakasunud-sunod ang tumakbo.

I-verify sa bagong koneksyon at hindi sa naka-save na sesyon, dahil ang kliyenteng muling kumokonekta mula sa cache ay maaaring lumaktaw sa mga bahagi ng pagpapalitan at muling gawin ang lumang resulta. Kumpirmahin ang maabot, pagpapalitan ng key, tunnel at PPP isa-isa, sa ganoong pagkakasunud-sunod. Pagkatapos ay tumitigil ang nawawalang tanong na maging palaisipan at nagiging ikalawang linya ng listahang talagang mapapagpatuloy mo. Ang listahang iyon din ang ibinibigay mo sa koponan ng network, na kung hindi ay hihilingin na suriin ang firewall dahil sa depektong nabubuhay sa daemon na hindi nasimulan.