Hokker VPN-stap mislearre: IPsec, L2TP-kontrôle of PPP-autentikaasje
Fyn de lêste stap dy’t slagge en reparearje allinnich dy laach: IPsec, it L2TP-kontrôlekanaal, PPP-autentikaasje of adrestawizing.
Jo hawwe it wachtwurd feroare en neat beweegde, om’t de flater nea yn PPP siet. L2TP/IPsec meldt ien ferbyningsflater foar fiif hiel ferskillende oerdrachten, en elke oerdracht hat syn eigen reparaasje. Wurkje efterstfoar: fyn de lêste stap dy’t slagge en feroarje allinnich wat dêrnei komt. De folchoarder hjirûnder beslút ek hokker bewiis jo earst sammelje.
Beäntwurdzje fjouwer fragen yn folchoarder
Twang in nije poging ôf, om’t guon kliïnten de foarige flater bliuwe sjen litte oant it profyl loskeppele en wer ferbûn wurdt. Beäntwurdzje dan dit: wie der in IPsec-feiligensassosjaasje, ferskynden in L2TP-kontrôleferbining en in oprop, berikte PPP in autentikaasje-oardiel, en joech IPCP de kliïnt in adres? It earste nee is de stap dy’t jo reparearje. Alles dêrnei is ûnteste, dus in wegere brûkersnamme bewiist neat as der nea in assosjaasje wie.
Syngronisearje de klokken oan beide kanten foar’t jo fergelykje. In nije poging dy’t IPsec skjinmakke en by PPP mislearre, liket ien flater as de kliïnt allinnich it lêste berjocht toant en it serverloch noch de eardere poging hâldt. Lês op tiidstimpel, net op de lûdst klinkende rigel.
As jo allinnich de skermprint fan de brûker hawwe, fertrou dan op de goedkeapste skieding: in ferkeard foarôf dield kaai en in xl2tpd dy’t nea antwurdet meitsje deselde tekst yn ‘e Windows-dialooch, mar de iene hat in geheim nedich dat oan beide kanten feroare wurdt en de oare in daemon dy’t start is of in firewallregel op ‘e server sels. In apparaat yn ‘e midden kin it ynnere 1701 net fuortsmite as IPsec yn ferfiersmodus it al ynpakt hat, dat sykje net nei in paadfilter dat der net is.
Wat elke laach eins besit
IPsec beskermet pakketten tusken de beide pearen; L2TP ferfiert in PPP-sesje binnen dat beskerme paad, dêrom spesifisearret RFC 3193 ferfiersmodus yn stee fan in eigen tunnel. It label fan ‘e kliïnt seit L2TP, dat de tunnel en de oanmelding fiele as ien meganisme. Dat binne se net: de L2TP-kontrôleferbining autentisearret de túneleinen wêr’t in ymplemintaasje dat oansette lit, en PPP autentisearret de brûker apart mei CHAP, PAP of MS-CHAPv2 neffens it serverbelied.
Dy skieding ferklearret de twa geheimen dy’t minsken hieltyd trochinoar helje. In foarôf dield kaai autentisearret de IPsec-pearen. In brûkersnamme en wachtwurd identifisearje de brûker foar PPP. It Windows-dielde geheim opnij ynfiere op in profyl dat mei sertifikaten autentisearret feroaret neat yn ‘e mislearjende stap, en it PPP-wachtwurd bewurkje kin gjin ûntbrekkend beskerme kanaal leverje. Deselde werhâlding jildt foar de identiteitskontrôle: skeakelje de identiteit fan it pear of sertifikaatfalidaasje net út om in tunnel te krijen, want dan ferbynt it paad, net it pear.
Autentikaasje is ek net it ein fan PPP. Nei’t de brûker akseptearre is, ûnderhannelt IPCP it kliïntadres en de DNS- en WINS-opsjes dy’t de server leverje wol. In kliïnt kin CHAP of MS-CHAPv2 helje en dochs sûnder adres einigje, wat in flater binnen PPP is en gjin routeringsprobleem. Ienfâldich L2TP sûnder IPsec bliuwt jildich en ûnbeskerme, dat in suksesfolle ferbining bewiist nea dat it ferkear beskerme is; kontrolearje wat de server easket, net it label fan ‘e kliïnt.
Beslis op basis fan ‘e earste ûntbrekkende stap
Lês de tabel op it earste ûntbrekkende ûnderdiel, fan links nei rjochts. De rjochterkolom is it iennige wurk dat op dat stuit de muoite wurdich is; alles links dêrfan is al bewiisd, en it opnij testen ferbrânt it ûnderbrekkingsfinster sûnder ynformaasje ta te foegjen.
| 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 |
Trije rijen fertsjinje in warskôging. De 1701-rigel is wêr’t Windows-kliïnten efter NAT meastentiids belânje: de assosjaasje foltôget, dan komt der neat, en ynkapseling is de oarsaak, net in min wachtwurd. De IPCP-rigel is dy’t ferkeard lêzen wurdt as in routeringsprobleem, om’t Windows in ûntbrekkend adres yn flater 720 ynpakt en it tray-ikoan allinnich seit dat de ferbining mislearre; dy flater sit nei autentikaasje en foar routering. De lêste rigel is hielendal gjin IPsec-flater, ek al seit it ikoan ferbrutsen.
Opdrachten dy’t de lagen skiede
Op in Linux-server mei strongSwan listet swanctl --list-sas fêstige assosjaasjes mei har peer-identiteit, en ipsec statusall dekt âldere strongSwan- en libreswan-hosts. Dêrûnder toant ip xfrm state de werklike assosjaasjes fan ‘e kernel, wylst ss -lunp | grep 1701 bewiist wêr’t xl2tpd bûn is. Start xl2tpd -D op ‘e foargrûn om kontrôleferbiningen en oproppen ferskine te sjen, en skeakelje pppd-ûntbuzing yn /etc/ppp/options.xl2tpd oan om de oanbeane metoade en it antwurd te sjen.
As de lochs in suksesfolle autentikaasje toane, is de folgjende fraach oft IPCP foltôge is. Kontrolearje oft ip range yn ‘e seksje [lns default] fan /etc/xl2tpd/xl2tpd.conf noch frije adressen hat, en oft /etc/ppp/options.xl2tpd wier ms-dns en ms-wins befettet as de kliïnt dy ferwachtet. In útputte pool en in ûntbrekkende DNS-opsje sjogge der oars út op ‘e tried: de earste lit de kliïnt sûnder adres en mei in 720, de twadde jout in adres mar gjin resolver, dat nammen mislearje wylst pings nei rauwe adressen wurkje. Gjin fan beide wurdt repareare troch it wachtwurd opnij yn te fieren.
Op ‘e kliïnt skriuwt de NetworkManager-L2TP-tafoeging it pppd-gesprek yn it deiboek, dat journalctl -u NetworkManager -b skiedt meastentiids tunnel omheech, autentikaasje wegere fan hielendal gjin tunnel. Op Windows rapportearret Get-VpnConnection de echte autentikaasjeynstellings fan it profyl, en de RasClient-eveneminten ûnder Application yn Event Viewer neame it mislearjende ûnderdiel. As de dialooch te ûndúdlik is, aktivearje netsh ras set tracing * enable.
Opnamen freegje ien foarsichtigens. Mei IPsec yn ferfiersmodus is de ynnere UDP 1701 fersifere, dat in opname op ‘e bûtenste ynterface toant ESP, of UDP 4500 ûnder NAT-T, en hielendal gjin L2TP. Ûntbrekkende 1701 yn in opname is ferwachte en gjin bewiis fan in blokkearre poarte; sjoch oft de ESP- of 4500-tellers bewege.
NAT, MTU en rûtes: wêr’t de stapel jo misliedt
NAT brekt oannames foar’t der wat autentisearre is. ESP is syn eigen IP-protokol, dat in oersetapparaat smyt it fuort, útsein as de pearen inkapselje; dat is wat UDP 4500 leveret. Op in Windows-server dy’t sels efter in thúsrouter of in wolk-NAT-poarte sit, mislearret de IPsec-stap mei flater 789 oant AssumeUDPEncapsulationContextOnSendRule ûnder de PolicyAgent-kaai op 2 set wurdt en de masine werstartet, en de flater bliuwt net te ûnderskieden fan in sletten poarte. Kliïnten efter NAT binne makliker: mei in iepenbier adres op ‘e server ferfiert NAT-T op UDP 4500 har en dy wearde is net belutsen.
As PPP omheech is, imitearret in MTU mei in swart gat in deade tunnel: lytse pakketten geane troch, in TLS-hânskodding of in sidenlading hinget, en de kliïnt kin noch ferbûn toane. Ferleegje de MTU fan ‘e ynterface of klam MSS by de poarte foar’t jo de server beskuldigje. Split-tunnel-routering is de oare bedrager; in subnet dat mei it ferkearde masker stjoerd wurdt lit de tunnel sûn en ien applikaasje ûnberikber. In privee hostnamme foeget syn eigen hop ta: as de fraach troch de lokale resolver fuortgiet, mislearret de namme foar’t in rûte testen wurdt.
Kontrollist foar’t jo oanmeldyndetails oanreitsje
Wurkje de list yn folchoarder troch en stopje by it earste mislearjende ûnderdiel. Elke stap is goedkeap, en elk slút in hiele klasse fan bewurkings út.
- Befêstigje dat de assosjaasje oan beide kanten bestiet, keppele op peer-identiteit yn stee fan in ferbûn-label.
- Befêstigje dat UDP 1701 xl2tpd berikt; in assosjaasje sûnder oprop is jo flater.
- Lês it oardiel fan PPP, en as it autentisearre, it IPCP-resultaat, foar’t jo oannimme dat it wachtwurd ferkeard is.
- No pas fiere jo de oanmeldyndetails opnij yn yn it formaat dat de server ferwachtet, om’t in domeinprefiks it akkount feroaret.
- As it noch mislearret, meitsje dan opnamen fan beide kanten mei byinoar passende tiidstimpels en fergelykje stap foar stap.
Stopje by stap twa betsjut in paad- of ynkapselingsprobleem, en gjin wachtwurdbewurking sil it bewege. Stopje by stap trije betsjut dat it loch de metoade of de adrespoel dy’t repareare moat al neamt. Yn beide gefallen is de folgjende feroaring ien dy’t jo rjochtfeardigje kinne, en jo hâlde op mei it rûngean troch ynstellings dy’t nea belutsen wiene.