Pa gam o’r VPN a fethodd: IPsec, rheolaeth L2TP neu ddilysu PPP
Dewch o hyd i’r cam olaf a lwyddodd, yna trwsiwch y haen honno’n unig: IPsec, sianel reoli L2TP, dilysu PPP neu ddyrannu cyfeiriad.
Fe wnaethoch chi newid y cyfrinair ac ni symudodd dim, oherwydd nid oedd y methiant erioed yn PPP. Mae L2TP/IPsec yn adrodd un gwall cysylltu ar gyfer pum trosglwyddiad hollol wahanol, ac mae gan bob trosglwyddiad ei atgyweiriad ei hun. Gweithiwch am yn ôl: dewch o hyd i’r cam olaf a lwyddodd a newidiwch yn unig yr hyn a ddaw ar ei ôl. Mae’r drefn isod hefyd yn penderfynu pa dystiolaeth rydych chi’n ei chasglu gyntaf.
Atebwch bedwar cwestiwn yn eu trefn
Gorfodwch ymgais newydd, oherwydd mae rhai cleientiaid yn dal i ddangos y gwall blaenorol nes bod y proffil yn cael ei ddatgysylltu a’i ailgysylltu. Yna atebwch hyn: oedd cymdeithas diogelwch IPsec yn bresennol, a ymddangosodd cysylltiad rheoli L2TP a galwad, a gyrhaeddodd PPP farn dilysu, ac a roddodd IPCP gyfeiriad i’r cleient? Y na cyntaf yw’r cam rydych chi’n ei drwsio. Mae popeth ar ei ôl heb ei brofi, felly nid yw enw defnyddiwr a wrthodwyd yn profi dim pan na fu cymdeithas erioed.
Cydamserwch y clociau ar y ddau ben cyn cymharu. Mae ail-esgoriad a gliriodd IPsec ac a fethodd yn PPP yn edrych fel un methiant pan fo’r cleient yn dangos y neges olaf yn unig ac mae cofnod y gweinydd yn dal yr ymgais gynharach. Darllenwch yn ôl stamp amser, nid yn ôl y llinell uchaf ei sŵn.
Pan mai cynllun sgrin y defnyddiwr yn unig sydd gennych, dibynnu ar y rhaniad rhataf: mae allwedd a rennir ymlaen llaw yn anghywir ac xl2tpd nad yw byth yn ateb yn cynhyrchu’r un testun yn y dialog Windows, eto mae un angen cyfrinach a newidir ar y ddau ben a’r llall angen daemon wedi’i gychwyn neu reol wal dân ar y gweinydd ei hun. Ni all dyfais yn y canol ollwng y 1701 mewnol unwaith y bydd IPsec mewn modd cludo wedi’i lapio, felly peidiwch â mynd i chwilio am hidlydd llwybr nad yw yno.
Beth mae pob haen yn ei berchen mewn gwirionedd
Mae IPsec yn amddiffyn pecynnau rhwng y ddau gyfoed; mae L2TP yn cario sesiwn PPP o fewn y llwybr gwarchodedig hwnnw, a dyna pam mae RFC 3193 yn pennu modd cludo yn hytrach na thwnnel ei hun. Mae label y cleient yn dweud L2TP, felly mae’r twnnel a’r mewngofnodi yn teimlo fel un mecanwaith. Nid ydynt: mae’r cysylltiad rheoli L2TP yn dilysu pennau’r twnnel lle mae defnydd yn ei alluogi, ac mae PPP yn dilysu’r defnyddiwr ar wahân gyda CHAP, PAP neu MS-CHAPv2 o dan bolisi’r gweinydd.
Mae’r rhaniad hwnnw’n esbonio’r ddwy gyfrinach y mae pobl yn parhau i’w cymysgu. Mae allwedd a rennir ymlaen llaw yn dilysu cyfoedion IPsec. Mae enw defnyddiwr a chyfrinair yn adnabod y defnyddiwr i PPP. Nid yw ail-deipio cyfrinach a rennir Windows ar broffil sy’n dilysu gyda thystysgrifau yn newid dim yn y cam sy’n methu, ac ni all golygu cyfrinair PPP ddarparu sianel warchodedig sydd ar goll. Mae’r un ymatal yn berthnasol i’r gwiriad hunaniaeth: peidiwch â diffodd hunaniaeth cyfoed na dilysu tystysgrif i gael twnnel, oherwydd yr hyn sy’n cysylltu wedyn yw’r llwybr, nid y cyfoed.
Nid dilysu yw diwedd PPP chwaith. Ar ôl derbyn y defnyddiwr, mae IPCP yn trafod cyfeiriad y cleient a’r opsiynau DNS a WINS y mae’r gweinydd yn fodlon eu rhoi. Gall cleient basio CHAP neu MS-CHAPv2 ac eto fod heb gyfeiriad, sy’n fethiant o fewn PPP yn hytrach na phroblem llwybro. Mae L2TP plaen heb IPsec yn parhau’n ddilys ac yn anwarchodedig, felly nid yw cysylltiad llwyddiannus byth yn profi bod y traffig wedi’i warchod; gwiriwch beth mae’r gweinydd yn ei fynnu, nid label y cleient.
Penderfynwch o’r cam cyntaf sydd ar goll
Darllenwch y tabl yn ôl yr eitem gyntaf sydd ar goll, o’r chwith i’r dde. Y golofn dde yw’r unig waith sy’n werth ei wneud ar y pryd; mae popeth i’w chwith eisoes wedi’i brofi, ac mae ail-brofi’r peth yn llosgi’r ffenestr amhariad heb ychwanegu gwybodaeth.
| 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 |
Mae tri rhes yn haeddu rhybudd. Rhes 1701 yw lle mae cleientiaid Windows y tu ôl i NAT yn tueddu i lanio: mae’r gymdeithas yn cwblhau, yna ni chyrhaedda dim, a’r encapswleiddio yw’r achos yn hytrach na chyfrinair gwael. Rhes IPCP yw’r un sy’n cael ei darllen yn anghywir fel problem llwybr, oherwydd mae Windows yn lapio cyfeiriad sydd ar goll yn nam 720 a dim ond dweud bod y cysylltiad wedi methu y mae eicon y hambwrdd; mae’r methiant hwnnw’n eistedd ar ôl dilysu ac o flaen llwybro. Nid yw’r rhes olaf yn fethiant IPsec o gwbl er bod yr eicon yn dweud datgysylltu.
Gorchmynion sy’n gwahanu’r haenau
Ar weinydd Linux sy’n rhedeg strongSwan, mae swanctl --list-sas yn rhestru cymdeithasau sefydledig gyda’u hunaniaeth cyfoed, ac mae ipsec statusall yn cwmpasu gwesteiwyr strongSwan a libreswan hŷn. O dan hynny mae ip xfrm state yn dangos cymdeithasau gwirioneddol y cnewyllyn, tra mae ss -lunp | grep 1701 yn profi lle mae xl2tpd wedi’i rwymo. Rheswch xl2tpd -D yn y blaendir i weld cysylltiadau rheoli a galwadau yn ymddangos, a throwch ymlaen dadgyfrifo pppd yn /etc/ppp/options.xl2tpd i weld y dull a gynigir a’r ateb.
Unwaith y bydd y cofnodion yn dangos dilysu llwyddiannus, y cwestiwn nesaf yw a gwblhaodd IPCP. Gwiriwch fod gan ip range yn adran [lns default] o /etc/xl2tpd/xl2tpd.conf gyfeiriadau rhydd o hyd, ac fod /etc/ppp/options.xl2tpd yn wir yn cario ms-dns a ms-wins os yw’r cleient yn eu disgwyl. Mae cronfa wedi’i dihysbyddu ac opsiwn DNS sydd ar goll yn edrych yn wahanol ar y wifren: mae’r cyntaf yn gadael y cleient heb gyfeiriad a chyda 720, mae’r ail yn rhoi cyfeiriad ond dim datryswr, felly mae enwau’n methu tra mae pings i gyfeiriadau crai yn gweithio. Nid oes y naill na’r llall yn cael ei drwsio trwy ail-nodi’r cyfrinair.
Ar y cleient mae ategyn L2TP NetworkManager yn ysgrifennu sgwrs pppd i’r cyfnodolyn, felly mae journalctl -u NetworkManager -b fel arfer yn gwahanu twnnel i fyny, dilysu wedi’i wrthod oddi wrth dim twnnel o gwbl. Ar Windows mae Get-VpnConnection yn adrodd gosodiadau dilysu gwirioneddol y proffil, ac mae digwyddiadau RasClient o dan Application yn Event Viewer yn enwi’r gydran sy’n methu. Pan fo’r dialog yn rhy amwys, galluogwch netsh ras set tracing * enable.
Mae angen un rhybudd ar gasgliadau. Gydag IPsec mewn modd cludo mae’r UDP 1701 mewnol wedi’i amgryptio, felly mae casgliad ar y rhyngwyneb allanol yn dangos ESP, neu UDP 4500 o dan NAT-T, a dim L2TP o gwbl. Mae 1701 ar goll mewn casgliad yn ddisgwyliedig ac nid yw’n brawf o borth wedi’i rwystro; gwyliwch a yw’r cownteri ESP neu 4500 yn symud.
NAT, MTU a llwybrau: lle mae’r pentwr yn eich twyllo
Mae NAT yn torri rhagdybiaethau cyn i unrhyw beth gael ei ddilysu. Mae ESP yn brotocol IP ei hun, felly mae dyfais sy’n cyfieithu yn ei daflu oni bai bod y cyfoedion yn encapswleiddio; dyna’n union a ddarperir gan UDP 4500. Ar weinydd Windows sydd ei hun y tu ôl i lwybrydd cartref neu borth NAT cwmwl, mae’r cam IPsec yn methu â gwall 789 nes bod AssumeUDPEncapsulationContextOnSendRule yn cael ei osod i 2 o dan allwedd PolicyAgent a’r peiriant yn ailgychwyn, ac mae’r methiant yn aros yn amhosibl ei wahaniaethu oddi wrth borth caeedig. Mae cleientiaid y tu ôl i NAT yn haws: gyda chyfeiriad cyhoeddus ar y gweinydd, mae NAT-T ar UDP 4500 yn eu cario ac nid yw’r gwerth hwnnw’n rhan o’r mater.
Unwaith y mae PPP i fyny, mae MTU â thyllau du yn efelychu twnnel marw: mae pecynnau bach yn croesi, mae ysgwyd llaw TLS neu lwytho tudalen yn hongian, ac efallai y bydd y cleient yn dal i ddangos cysylltiedig. Gostyngwch MTU’r rhyngwyneb neu gymalwch MSS yn y porth cyn beio’r gweinydd. Llwybro twnnel hollt yw’r twyllwr arall; mae is-rwydwaith a wthir gyda’r mwgwd anghywir yn gadael y twnnel yn iach ac un cymhwysiad yn uncyrraeddadwy. Mae enw gwesteiwr preifat yn ychwanegu cam ei hun: os yw’r ymholiad yn gadael drwy’r datryswr lleol, mae’r enw’n methu datrys cyn i unrhyw lwybr gael ei brofi.
Rhestr wirio cyn i chi gyffwrdd â chyfriflyfr
Gweithiwch y rhestr yn ei thro a stopiwch ar yr eitem gyntaf sy’n methu. Mae pob cam yn rhad, ac mae pob un yn diystyru dosbarth cyfan o olygiadau.
- Cadarnhewch fod y gymdeithas yn bodoli ar y ddau ben, wedi’i pharu yn ôl hunaniaeth cyfoed yn hytrach na label cysylltiedig.
- Cadarnhewch fod UDP 1701 yn cyrraedd xl2tpd; cymdeithas heb alwad yw eich methiant.
- Darllenwch farn PPP, ac os y dilysodd, ganlyniad IPCP, cyn tybio bod y cyfrinair yn anghywir.
- Dim ond nawr ail-nodwch gyfriflyfr yn y fformat y mae’r gweinydd yn ei ddisgwyl, oherwydd mae rhagddodiad parth yn newid y cyfrif.
- Os yw’n dal i fethu, casglwch y ddau ben gyda stampiau amser wedi’u halinio a chymharwch gam wrth gam.
Mae stopio yng ngham dau yn golygu problem llwybr neu encapswleiddio, ac ni fydd unrhyw olygiad i’r cyfrinair yn ei symud. Mae stopio yng ngham tri yn golygu bod y cofnod eisoes yn enwi’r dull neu’r gronfa gyfeiriadau i’w thrwsio. Yn y naill ffordd neu’r llall, y newid nesaf yw un y gallwch chi ei gyfiawnhau, ac rydych chi’n rhoi’r gorau i gylchdroi drwy osodiadau nad oeddent byth yn rhan o’r mater.