Pam mae PPTP a L2TP/IPsec yn stopio cyn yr anogwr enw defnyddiwr?

Mae diffyg anogwr enw defnyddiwr yn anrheg ddiagnostig: nid yw PPP wedi dechrau eto, felly nid ymgynghorwyd â'r cyfrif, y cyfrinair na pholisi'r parth. Mewn cysylltiad PPTP neu L2TP/IPsec dim ond ar ôl i'r twnnel fodoli ac i'r gweinydd ddechrau sesiwn PPP y mae'r cleient yn gofyn am gymwysterau. Popeth a allai fethu cyn y foment honno yw cludiant, cyfnewid allweddi neu osodiad twnnel, sy'n arwynebedd llawer llai na „mae'r VPN wedi torri”.

Mae anogwr coll yn culhau'r nam i dri cham

Nodwch y cam olaf a lwyddodd yn weladwy, oherwydd mae gan bob un berchennog gwahanol a chyweiriad gwahanol. Dyfalu gosodiadau'r cyfrif tra'ch bod wedi stwffio dau gam yn gynharach yw sut mae prynhawn yn diflannu.

Nid yw cleient sy'n dod i ben heb anogwr erioed wedi cael cymdeithas IPsec, felly mae'r nam yn IKE neu yn yr hyn a wna eich pecynnau gyrraedd y porth o gwbl. Un sy'n nodi ei fod yn gwirio cymwysterau ac yna'n disgyn aeth ymhellach nag y mae'r neges yn ei awgrymu. Anogwr a ddilynir gan wrthodiad yw dilysiad PPP, ac mae hynny'n perthyn i erthygl cyfrif yn hytrach nag i'r un hon.

Cam un: y protocol y mae mur tân yn ei ollwng yn dawel

Mae PPTP angen TCP 1723 ar gyfer ei sianel reoli a phrotocol IP 47 ar gyfer y llwybr data, ac mae'r ddau yn teithio ar wahân. Mae llawer o rwydweithiau yn anfon 1723 ymlaen ac yn gollwng protocol 47, sy'n cynhyrchu twnnel sy'n trafod ac yna'n cario dim o gwbl. Mae angen pas i mewn â chefnogaeth GRE ar lwybrydd sy'n gwneud NAT hefyd, ac ni all llwybr mynediad IPv6 yn unig gario PPTP o dan unrhyw ffurfweddiad.

Mae L2TP dros IPsec yn gwario porth 500 ar IKE a phorth 4500 ar drawsfa NAT, yna'n lapio traffig L2TP ei hun mewn 1701, tra bod ESP yn cario'r llwyth a warchodir unwaith y bydd y gymdeithas yn bodoli. Caniatáu'r ddau borth rheoli ond nid ESP a chewch yn union y symptom yn y teitl: cynnydd gweladwy, yna cleient marw cyn unrhyw ddeialog cymwysterau. Mae profi o hotspot ffôn yn ffordd rhad o wahanu problem cleient oddi wrth broblem llwybr.

Cam dau: allwedd nad yw'n allwedd, cynnig na chynigir

Mae allwedd a rannwyd ymlaen llaw nad yw'n cyfateb yn methu'n gyflym ac yn dawel, a'r fersiwn arferol yw allwedd sy'n edrych yn gywir ar y sgrin tra'i bod yn cario toriad llinell gludiedig neu ofod ar y diwedd. Ar gleient Linux nid y deialog yw ffynhonnell y gwirionedd o reidrwydd: mae ategyn L2TP NetworkManager yn cadw cyfrinachau mewn ffeiliau o dan /etc/ipsec.d/, a bydd hen ffeil fesul cysylltiad y mae /etc/ipsec.secrets yn dal i'w chynnwys yn cael ei defnyddio'n lle'r un a deipiwyd gennych yn awr. Copïwch y ffeil honno i le diogel, tynnwch hi o'r llwybr cynnwys, yna teipiwch yr allwedd â llaw.

Hanner arall y cam hwn yw'r cynnig. Rhaid i'r ddau ben setlo ar yr un set o algorithmau cam 1 — amgryptio, cyfanrwydd a grŵp Diffie-Hellman — ac ar drawsffurfiadau ESP cyfatebol ar gyfer cam 2, neu ni ffurfir y gymdeithas o gwbl. Bydd porth sy'n cynnig 3DES, SHA1 a MODP1024 yn unig yn gwrthod cleient a ffurfweddwyd ar gyfer algorithmau cryfach, ac mae ei log yn enwi'r drawsffurfiad a wrthodwyd. Mae'r log yn enwi'r anghysondeb os ydych chi'n ei ddarllen yn lle ailgychwyn y gwasanaeth eto. Yn lle copïo llinyn algorithm o edefyn fforwm, gofynnwch i'r porth ba drawsffurfiadau y bydd yn eu trafod mewn gwirionedd: mae ike-scan wedi'i anelu at ei chyfeiriad yn dychwelyd y drawsffurfiadau y bydd yn eu trafod. Os mai'r unig gynnig yw cryptograffeg nad yw eich polisi'n ei chaniatáu mwyach, mae'r cyweiriad yn perthyn i'r porth, nid i ddiraddio'r cleient.

Ar Windows mae'r allwedd a'r dull dilysu yn byw yn y proffil VPN, ac mae anghysondeb yn codi cyn yr anogwr cymwysterau yn hytrach nag ar ei ôl. Lle'r derbynnydd yw Windows Server, cadarnhewch fod y rôl mynediad o bell wedi'i gosod, fod y dystysgrif yn cyfateb i'r enw y mae cleientiaid yn cysylltu ag ef, ac nad oes hidlydd porth yn gulach na'r protocolau uchod.

Cam tri: mae'r twnnel yn bodoli ac nid yw PPP yn dechrau

Pan fydd IKE wedi cwblhau a'r anogwr yn dal i beidio ag ymddangos, edrychwch ar y demon twnnel yn hytrach na'r mur tân. Mae L2TP angen rhywbeth sy'n gwrando ar UDP 1701 — xl2tpd neu kl2tpd ar Linux, y gwasanaeth mynediad o bell ar Windows — ac mae gwasanaeth sydd wedi'i osod ond wedi stopio yn edrych o du'r cleient yr un fath â phecyn a ollyngwyd. Gwiriwch y gwrandawr cyn ailagor rheolau yr ydych eisoes wedi'u gwirio. Yna rhaid i PPP drafod, a'r gyfnewid LCP gyntaf yw lle mae methiant tawel fel arfer yn glanio.

Nid yw un trap yn y cam hwn yn nam rhwydwaith o gwbl: mae Windows yn caniatáu un cysylltiad o fath VPN penodol ar y tro, felly mae ail ymgais yn dychwelyd gwall 937, „mae cysylltiad arall o'r math hwn yn cael ei ddefnyddio”. Rheol leol yw hon, a'r ffordd o'i osgoi yw dyfais wahanol, math twnnel gwahanol, neu rannu'r un cysylltiad sydd eisoes yn bod.

Darllenwch y log yng nhrefn y camau yn hytrach na dyfalu

Stopiwch y cleient, ei gychwyn eto, a darllen y cydrannau yn y drefn y maent yn ysgrifennu log. Hynny yw'r demon IPsec yn gyntaf — strongSwan neu Libreswan, ac mae ipsec --version yn dweud wrthych pa un — yna'r demon L2TP, yna pppd. Pa bynnag gydran a ysgrifennodd ddiwethaf cyn y methiant sy'n nodi'r cam i ymchwilio iddo, oherwydd ni redodd dim byd sy'n dod ar ei ôl yn y dilyniant o gwbl.

Gwiriwch â chysylltiad ffres yn hytrach na sesiwn a gadwyd, oherwydd gall cleient sy'n ailgysylltu o'r storfa neidio dros rannau o'r gyfnewid ac atgynhyrchu canlyniad hen ffasiwn. Cadarnhewch gyrhaeddiad, cyfnewid allweddi, twnnel a PPP un ar y tro, yn y drefn honno. Yna mae'r anogwr coll yn peidio â bod yn ddirgelwch ac yn dod yn ail linell rhestr y gellir gweithio drwyddi mewn gwirionedd. Y rhestr honno hefyd yw'r hyn yr ydych yn ei rhoi i'r tîm rhwydwaith, y byddid fel arall yn gofyn iddo wirio'r mur tân am nam sy'n byw mewn demon nas cychwynnwyd.