Hvaða VPN-skref mistókst: IPsec, L2TP-stýring eða PPP-auðkenning

Þú breyttir lykilorðinu og ekkert hreyfðist, því bilunin var aldrei í PPP. L2TP/IPsec tilkynnir eina tengivillu fyrir fimm mjög ólíka afhendingu, og hver afhending hefur sína eigin lagfæringu. Vinnðu aftur á bak: finndu síðasta skrefið sem tókst og breyttu aðeins því sem kemur á eftir. Röðin hér að neðan ræður því líka hvaða sönnunargögn þú safnar fyrst.

Svaraðu fjórum spurningum í röð

Þvingaðu nýja tilraun, því sumir biðlarar sýna fyrri villuna þar til prófíllinn er aftengdur og tengdur aftur. Svaraðu svo þessu: var IPsec-öryggistengsl til staðar, birtust L2TP-stýritenging og símtal, náði PPP auðkenningardómi, og gaf IPCP biðlaranum vistfang? Fyrsta nei er skrefið sem þú lagar. Allt sem á eftir kemur er óprófað, svo hafnað notandanafn sannar ekkert þegar engin tengsl voru nokkurn tíma.

Samstilltu klukkurnar á báðum endum áður en þú berð saman. Endurtilraun sem hreinsaði IPsec og mistókst á PPP lítur út eins og ein bilun þegar biðlarinn sýnir aðeins síðustu skilaboðin og þjónninn geymir enn fyrri tilraunina. Lestu eftir tímastimpli, ekki eftir háværustu línunni.

Þegar þú hefur aðeins skjáskot notandans skaltu treysta á ódýrustu skiptinguna: rangt fyrirfram deilt lykil og xl2tpd sem svarar aldrei framleiða sama texta í Windows-glugganum, en annar þarf leyndarmál sem breytt er á báðum endum og hinn þarf vinna í gangi eða eldveggjarreglu á þjóninum sjálfum. Tæki í miðjunni getur ekki sleppt innra 1701 þegar IPsec í flutningsham hefur vafið það inn, svo ekki leita að slóðasíu sem er ekki til.

Hvað hvert lag á í raun

IPsec verndar pakka milli jafningjanna tveggja; L2TP flytur PPP-lotu inni í þeirri vernduðu slóð, þess vegna tilgreinir RFC 3193 flutningsham í stað eigin gönga. Merki biðlarans segir L2TP, svo göngin og innskráningin virðast ein kerfi. Þau eru það ekki: L2TP-stýritengingin auðkennir enda ganganna þar sem uppsetning kveikir á því, og PPP auðkennir notandann sérstaklega með CHAP, PAP eða MS-CHAPv2 samkvæmt stefnu þjónsins.

Þessi skipting útskýrir leyndarmálin tvö sem fólk ruglar saman. Fyrirfram deildur lykill auðkennir IPsec-jafningjana. Notandanafn og lykilorð auðkenna notandann gagnvart PPP. Að slá deilt leyndarmál Windows aftur inn á prófíl sem auðkennir með skírteinum breytir engu á því skrefi sem mistekst, og að breyta PPP-lykilorðinu getur ekki séð um vantaða verndaða rás. Sama aðhald gildir um auðkennisprófunina: slökktu ekki á auðkenni jafnings eða skírteinisstaðfestingu til að fá göng, því þá tengist slóðin, ekki jafninginn.

Auðkenning er heldur ekki endir PPP. Eftir að notandinn er samþykktur semur IPCP um vistfang biðlarans og DNS- og WINS-valkostina sem þjónninn er til í að gefa. Biðlari getur staðið CHAP eða MS-CHAPv2 og samt endað án vistfangs, sem er bilun inni í PPP en ekki leiðarvalkvæði. Óbreytt L2TP án IPsec helst gilt og óvarið, svo árangursrík tenging sannar aldrei að umferðin sé vernduð; athugaðu hvað þjónninn krefst, ekki merki biðlarans.

Ákveddu út frá fyrsta skrefinu sem vantar

Lestu töfluna eftir fyrsta atriðinu sem vantar, frá vinstri til hægri. Hægri dálkurinn er eina vinnan sem er þess virði á þeirri stundu; allt vinstra við hann er þegar sannað, og að prófa það aftur brennir truflunarglugganum án þess að bæta við upplýsingum.

Þrjár raðir eiga skilið viðvörun. Röð 1701 er þar sem Windows-biðlarar bak við NAT lenda venjulega: tengslin klárast, svo kemur ekkert, og orsökin er innpakning en ekki slakt lykilorð. Röð IPCP er sú sem er misskilin sem leiðarvandamál, því Windows vefur vantað vistfang inn í villu 720 og tákn á bakkanum segir aðeins að tengingin mistókst; sú bilun situr eftir auðkenningu og fyrir leiðarval. Síðasta röðin er alls ekki IPsec-bilun þótt táknið segi aftengt.

Skipanir sem aðskilja lögin

Á Linux-þjóni með strongSwan listar swanctl --list-sas stofnuð tengsl með auðkenni jafnings, og ipsec statusall nær yfir eldri strongSwan- og libreswan-vélar. Undir því sýnir ip xfrm state raunveruleg tengsl kjarnans, en ss -lunp | grep 1701 sannar hvar xl2tpd er bundið. Keyrðu xl2tpd -D í forgrunni til að sjá stýritengingar og símtöl birtast, og kveiktu á pppd-kembifærslu í /etc/ppp/options.xl2tpd til að sjá aðferðina sem boðin er og svarið.

Þegar annáll sýnir árangursríka auðkenningu er næsta spurning hvort IPCP kláraðist. Athugaðu hvort ip range í hlutanum [lns default] í /etc/xl2tpd/xl2tpd.conf hafi enn laus vistföng, og hvort /etc/ppp/options.xl2tpd beri raunverulega ms-dns og ms-wins ef biðlarinn væntir þeirra. Tæmd laug og vantandi DNS-valkostur líta öðruvísi út á vírnum: fyrri skilur biðlarann eftir án vistfangs og með 720, seinni gefur vistfang en engan leysanda, svo nöfn mistakast á meðan ping á hrá vistföng virkar. Hvort tveggja er ólagað með því að slá lykilorðið aftur inn.

Á biðlaranum skrifar NetworkManager-L2TP-viðbótin pppd-samtalið í annálinn, svo journalctl -u NetworkManager -b aðskilur venjulega göng uppi, auðkenningu hafnað frá engin göng yfirleitt. Á Windows tilkynnir Get-VpnConnection raunverulegar auðkenningarstillingar prófílsins, og RasClient-atburðir undir Application í Event Viewer nefna íhlutinn sem bregst. Þegar glugginn er of óljós skaltu virkja netsh ras set tracing * enable.

Upptökur krefjast einnar varúðar. Með IPsec í flutningsham er innra UDP 1701 dulkóðað, svo upptaka á ytri hlið sýnir ESP, eða UDP 4500 undir NAT-T, og alls ekki L2TP. Að 1701 vanti í upptöku er vænlegt og ekki sönnun um lokaða höfn; fylgstu með hvort ESP- eða 4500-teljarar hreyfast.

NAT, MTU og leiðir: þar sem stakkurinn blekkir þig

NAT brýtur forsendur áður en nokkuð er auðkennt. ESP er sinn eigin IP-samskiptareglur, svo þýðandi tæki hendir því nema jafningjarnir vefji því inn; það er það sem UDP 4500 veitir. Á Windows-þjóni sem stendur sjálfur bak við heimalið eða NAT-gátt í skýi mistekst IPsec-skrefið með villu 789 þar til AssumeUDPEncapsulationContextOnSendRule er sett á 2 undir PolicyAgent-lyklinum og vélin endurræst, og bilunin er óaðgreinanleg frá lokaðri höfn. Biðlarar bak við NAT eru auðveldari: með opinbert vistfang á þjóninum flytur NAT-T á UDP 4500 þá og það gildi kemur ekki við sögu.

Þegar PPP er uppi líkir MTU með svartholi eftir dauðum göngum: litlir pakkar komast í gegn, TLS-handaband eða síðuhleðsla stöðvast, og biðlarinn kann enn að sýna tengt. Lækkaðu MTU tengisins eða þrýstu MSS á gáttinni áður en þú kennir þjóninum um. Leiðarval klofinna ganga er hinn svindlarinn; undirnet sem ýtt er með röngu grímunni skilur göngin heil og eitt forrit óaðgengilegt. Einkarekin vélarheiti bætir við sínu eigin stökki: ef fyrirspurnin fer út um staðbundna leysandann tekst heitið ekki að leysast áður en nokkur leið er prófuð.

Gátlisti áður en þú snertir skilríki

Farðu í gegnum listann í röð og stöðvaðu við fyrsta atriðið sem bregst. Hvert skref er ódýrt, og hvert þeirra útilokar heilan flokk breytinga.

1. Staðfestu að tengslin séu til á báðum endum, pöruð eftir auðkenni jafnings en ekki tengt-merki.
2. Staðfestu að UDP 1701 nái til xl2tpd; tengsl án símtals eru bilunin þín.
3. Lestu dóm PPP og, ef það auðkenndi, niðurstöðu IPCP, áður en þú gerir ráð fyrir að lykilorðið sé rangt.
4. Aðeins núna skaltu slá skilríkin aftur inn í því sniði sem þjónninn væntir, því lénsforskeyti breytir reikningnum.
5. Ef það mistekst enn skaltu taka upp báða enda með samstilltum tímastimplum og bera saman skref fyrir skref.

Að stöðva við annað skrefið þýðir slóðar- eða innpakningsvandamál, og engin lykilorðsbreyting hreyfir það. Að stöðva við þriðja skrefið þýðir að annállinn nefnir þegar aðferðina eða vistfangalauguna sem á að laga. Í báðum tilvikum er næsta breyting ein sem þú getur réttlætt, og þú hættir að hringsnúast um stillingar sem komu aldrei við sögu.