Dat L2TP-adres is IPCP, gjin DHCP-lien op it LAN

De ferbining komt op en de adapter lit in adres sjen yn it berik fan it kantoar, dat de natuerlike konklúzje is dat de VPN dy in LAN-adres joech en dy dêrmei op it LAN sette. Gjin fan beide helten is hielendal goed. L2TP draacht in PPP-sesje, en PPP ûnderhannelet it binnenste IPv4-adres mei IPCP. Dat adres is in sesjeparameter dy’t tusken twa partijen ôfpraat wurdt, gjin lien dat de DHCP-tsjinner fan it kantoar útjout, en it hawwen derfan makket dy gjin buorman op ’e kantoardraad.

Twa adressen yn ien ferbining

Der binne twa ûnôfhinklike ûnderhannelings yn in L2TP-ferbining. De bûtenste leit in beskerme paad oan tusken dyn apparaat en it VPN-einpunt oer hokker netwurk dan ek datst al hast. De binnenste is de PPP-sesje, en dêr wurde dyn sesje-adres en it adres fan ’e oare kant ôfpraat. Ynternetferkear kin hielendal ûnder in tredde adres fuortgean, it iepenbiere adres fan it einpunt, en dêrom komme in VPN-kontrôle-side en it adres fan ’e adapter selden oerien.

Dy trije rollen apart hâlde be-antwurdet de measte fragen dy’t minsken nei dizze laach bringe. In priveenummer op ’e VPN-ynterface is normaal en ferwachtet. It seit neat oer oft it einpunt dyn iepenbiere útgong feroare hat, en it beslút op himsels net hokker bestimmingen dyn ferkear berikt.

Wat IPCP krekt docht

IPCP is it IPv4-kontrôleprotokol foar PPP. Eltse kant stjoert Configure-Request-berjochten dy’t de opsjes beskriuwe dy’t er wol, en de adresopsje is ien fan harren. In klant dy’t noch gjin adres hat, freget meastentiids mei 0.0.0.0, en de tsjinner antwurdet mei in Configure-Nak dy’t it adres draacht dat er de klant brûke litte wol. Dêrnei freget de klant dat adres oan, en de sesje komt op mei in lokaal en in ôfstân adres.

Dy útwikseling is dokumintearre yn ’e PPP- en IPCP-specifikaasjes, en se ferklearret in detail dat op in bug liket: it adres wurdt troch de tsjinner keazen út syn eigen belied, dat in pool, in ynstelling per brûker of in adres ferbûn oan ’e autentisearre identiteit wêze kin. As de pool útput is, of it belied mei it fersyk botst, kin autentikaasje slagje wylst adresûnderhanneling mislearret, en de klant rapportearret in ferbining dy’t nea ta rêst komt.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

In pppd-lochline dy’t in lokaal en in ôfstân adres neamt, is it suksesfolle ein fan dy ûnderhanneling. It ûntbrekken derfan, njonken in suksesfolle autentikaasje, wiist nei it adresstadium ynstee fan nei de oanmeldgegevens.

Wêrom’t it LAN dy net antwurdzje kin

In adres út it berik fan ’e fiere kant makket de ferwachting dat hosts op dat LAN dy berikke kinne, en meastentiids kinne se dat net, útsein as de tsjinner dyn sesje-adres werom yn ’e tunnel rjochtet. Yn in pool wêze is in útspraak oer tawizing, net oer topology. De bestânstsjinnder fan it kantoar hat gjin rûte nei dyn sesje-adres, útsein as de VPN-tsjinner it trochstjoert, en it mei miskien sels net tastien wêze as er dat docht.

Dêrom feroarsaakje oerlaapjende berikken problemen dy’t bûten ferhâlding steane mei har skynbere grutte. As de pool oerlaapet mei in LAN dat de klant al brûkt, hat de rûtetabel fan ’e klant no twa oanspraken op itselde foarheaksel, en de ferkearde wint faak om redenen dy’t neat mei de tunnel te meitsjen hawwe.

Kontrolearje de sesje, dan de rûte

Kontrolearje earst de ynterface, dan de rûtes, dan ien bestimming dy’t fan belang is. Elk stadium hat syn eigen wize fan mislearjen, en alle trije tagelyk testen jout in konklúzje dy’tst letter net ferdigenje kinst.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

As de iepenbiere kontrôle it adres fan it einpunt sjen lit wylst in privee bestimming ferfalt, draacht de tunnel dyn standertrûte en antwurdet de fiere kant net foar dy bestimming. As de privee bestimming antwurdet mar de iepenbiere kontrôle feroaret net, brûkt it profyl splitst tunneljen en brûkt mar in part fan it ferkear de sesje.

Hâld de trije stadia apart

Autentikaasje, adresûnderhanneling en trochstjoering mislearje ferskillend, en elk hat in oare eigner. Oanmeldgegevens binne in identiteitsprobleem, IPCP-útputting is in tsjinnerbeliedsprobleem, en in ûntbrekkende weromrûte is in netwurkûntwerpprobleem. Alle trije as “de VPN is stikken” melde garandearret in stadige oplossing.

Skriuw it tawiisde adres op, de pool dêr’t it wei kaam en oft it LAN it berikke moat. Dy iene notysje foarkomt dat de folgjende persoan in DHCP-lien oannimt en siket nei in berik dat nea belutsen wie.