Tas L2TP adresas yra IPCP, o ne DHCP nuoma LAN tinkle

Vidinis adresas gaunamas iš PPP derybų, o ne iš biuro DHCP serverio. Pažiūrėkite, kuris etapas jį priskiria, kodėl LAN negali atsakyti ir ką tikrinti.

Ryšys užsimezga ir adapteris rodo adresą biuro diapazone, todėl natūrali išvada, kad VPN davė jums LAN adresą ir taip jus įkėlė į LAN. Nė viena iš tų dviejų pusių nėra visiškai teisinga. L2TP perduoda PPP sesiją, o PPP su IPCP derasi dėl vidinio IPv4 adreso. Tas adresas yra sesijos parametras, dėl kurio susitaria dvi šalys, o ne biuro DHCP serverio išduota nuoma, ir jo turėjimas nepadaro jūsų kaimynu biuro laide.

Du adresai viename ryšyje

L2TP ryšyje vyksta dvi nepriklausomos derybos. Išorinė sukuria apsaugotą kelią tarp jūsų įrenginio ir VPN galinio taško per bet kokį jau turimą tinklą. Vidinė yra PPP sesija, ir būtent joje susitariama dėl jūsų sesijos adreso ir kitos pusės adreso. Interneto srautas gali išeiti visai kitu adresu – viešuoju galinio taško adresu, todėl VPN patikros puslapis ir adapterio adresas retai sutampa.

Šių trijų vaidmenų atskyrimas atsako į daugumą klausimų, kuriuos žmonės atneša į šį sluoksnį. Privatus numeris VPN sąsajoje yra normalu ir tikėtina. Jis nieko nesako apie tai, ar galinis taškas pakeitė jūsų viešą išėjimą, ir pats savaime nenusprendžia, kuriuos tikslus pasiekia jūsų srautas.

Ką tiksliai daro IPCP

IPCP yra PPP IPv4 valdymo protokolas. Kiekviena pusė siunčia Configure-Request pranešimus, apibūdinančius norimas parinktis, ir adreso parinktis yra viena iš jų. Klientas, dar neturintis adreso, paprastai prašo su 0.0.0.0, o serveris atsako Configure-Nak su adresu, kurį nori, kad klientas naudotų. Tada klientas prašo to adreso, ir sesija pakyla su vietiniu ir nuotoliniu adresu.

Šis pasikeitimas dokumentuotas PPP ir IPCP specifikacijose, ir jis paaiškina detalę, kuri atrodo kaip klaida: adresą serveris pasirenka pagal savo politiką, kuri gali būti telkinys, nuostata vienam naudotojui arba su autentifikuota tapatybe susietas adresas. Kai telkinys išsenka arba politika prieštarauja užklausai, autentifikacija gali pavykti, o adreso derybos nepavykti, ir klientas praneša apie ryšį, kuris niekada nusistovi.

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

pppd žurnalo eilutė, kurioje nurodytas vietinis ir nuotolinis adresas, yra sėkminga tų derybų pabaiga. Jos nebuvimas šalia sėkmingos autentifikacijos rodo adreso etapą, o ne prisijungimo duomenis.

Kodėl LAN negali jums atsakyti

Adresas iš tolimosios pusės diapazono sukuria lūkestį, kad to LAN tinkle esantys kompiuteriai jus pasieks, tačiau dažniausiai nepasiekia, nebent serveris nukreipia jūsų sesijos adresą atgal į tunelį. Buvimas telkinyje yra teiginys apie paskirstymą, o ne apie topologiją. Biuro failų serveris neturi maršruto į jūsų sesijos adresą, nebent VPN serveris jį persiunčia, o gal net ir neleidžiama, net jei persiunčia.

Štai kodėl persidengiantys diapazonai kelia problemų, neproporcingų jų matomam dydžiui. Jei telkinys persidengia su LAN, kurią klientas jau naudoja, kliento maršrutų lentelėje dabar yra du reikalavimai tam pačiam prefiksui, ir neteisingas dažnai laimi dėl priežasčių, neturinčių nieko bendra su tuneliu.

Pirmiausia patikrinkite sesiją, tada maršrutą

Pirmiausia patikrinkite sąsają, tada maršrutus, tada vieną svarbų tikslą. Kiekvienas žingsnis turi savo gedimo būdą, o visus tris tikrinant iš karto gaunama išvada, kurios vėliau negalėsite apginti.

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

Jei vieša patikra rodo galinio taško adresą, o privatus tikslas baigiasi skirtuoju laiku, tunelis neša jūsų numatytąjį maršrutą ir tolimoji pusė į tą tikslą neatsako. Jei privatus tikslas atsako, bet vieša patikra nesikeičia, profilis naudoja skaidrų tuneliavimą ir sesiją naudoja tik dalis srauto.

Laikykite tris etapus atskirai

Autentifikacija, adreso derybos ir persiuntimas nepavyksta skirtingai, ir kiekvienas turi skirtingą atsakingąjį. Prisijungimo duomenys yra tapatybės problema, IPCP išsekimas yra serverio politikos problema, o trūkstamas grįžtamasis maršrutas yra tinklo projektavimo problema. Pranešti apie visus tris kaip „VPN sugedusi“ garantuoja lėtą taisymą.

Užsirašykite priskirtą adresą, telkinį, iš kurio jis atėjo, ir ar LAN turėtų jį pasiekti. Ta viena pastaba neleidžia kitam žmogui manyti, kad tai DHCP nuoma, ir ieškoti srities, kuri niekada nebuvo susijusi.

Susiję straipsniai