Tiu L2TP-adreso estas IPCP, ne DHCP-luo en la LAN

La konekto ekfunkcias kaj la adaptilo montras adreson en la oficeja gamo, do la natura konkludo estas, ke la VPN donis al vi LAN-adreson kaj tiel metis vin en la LAN. Neniu el la du duonoj estas tute ĝusta. L2TP portas PPP-sesion, kaj PPP intertraktas la internan IPv4-adreson per IPCP. Tiu adreso estas sesia parametro interkonsentita inter du partneroj, ne luo eldonita de la oficeja DHCP-servilo, kaj ĝia posedo ne faras vin najbaro sur la oficeja drato.

Du adresoj en unu konekto

Ekzistas du sendependaj intertraktadoj en L2TP-konekto. La ekstera starigas protektitan vojon inter via aparato kaj la VPN-finpunkto super kia ajn reto vi jam havas. La interna estas la PPP-sesio, kaj tie oni interkonsentas vian sesian adreson kaj la adreson de la kontraŭa flanko. Interreta trafiko povas eliri tute sub tria adreso, la publika adreso de la finpunkto, kaj tial VPN-kontrolpaĝo kaj la adaptila adreso malofte kongruas.

Teni tiujn tri rolojn apartaj respondas al plej multaj demandoj, kiujn homoj alportas al ĉi tiu tavolo. Privata numero sur la VPN-interfaco estas normala kaj atendata. Ĝi diras nenion pri tio, ĉu la finpunkto ŝanĝis vian publikan eliron, kaj ĝi mem ne decidas, kiujn celojn via trafiko atingas.

Kion ĝuste faras IPCP

IPCP estas la IPv4-kontrolprotokolo por PPP. Ĉiu flanko sendas Configure-Request-mesaĝojn priskribantajn la opciojn, kiujn ĝi volas, kaj la adresa opcio estas unu el ili. Kliento, kiu ankoraŭ ne havas adreson, kutime demandas per 0.0.0.0, kaj la servilo respondas per Configure-Nak portanta la adreson, kiun ĝi volas, ke la kliento uzu. Poste la kliento petas tiun adreson, kaj la sesio ekfunkcias kun loka kaj fora adreso.

Tiu interŝanĝo estas dokumentita en la specifoj de PPP kaj IPCP, kaj ĝi klarigas detalon, kiu aspektas kiel cimo: la adreson elektas la servilo laŭ sia propra politiko, kiu povas esti baseno, agordo por unu uzanto aŭ adreso ligita al la aŭtentikigita identeco. Kiam la baseno elĉerpiĝas, aŭ la politiko kontraŭas la peton, aŭtentikigo povas sukcesi dum la adresa intertraktado malsukcesas, kaj la kliento raportas konekton, kiu neniam stabiliĝas.

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

Linio en la pppd-protokolo, kiu nomas lokan kaj foran adreson, estas la sukcesa fino de tiu intertraktado. Ĝia manko, apud sukcesa aŭtentikigo, montras al la adresa fazo anstataŭ al la akreditaĵoj.

Kial la LAN ne povas respondi al vi

Adreso el la gamo de la fora flanko kreas la atendo, ke gastigantoj en tiu LAN povas atingi vin, kaj plej ofte ili ne povas, krom se la servilo enkursigas vian sesian adreson reen en la tunelon. Esti ene de baseno estas aserto pri asignado, ne pri topologio. La dosier-servilo de la oficejo havas neniun itineron al via sesia adreso, krom se la VPN-servilo plusendas ĝin, kaj eble tio eĉ ne estas permesita, eĉ se ĝi faras.

Tial ankaŭ interkovrantaj gamoj kaŭzas problemojn malproporciajn al sia ŝajna grando. Se la baseno interkovras LAN, kiun la kliento jam uzas, la enkursiga tabelo de la kliento nun havas du postulojn pri la sama prefikso, kaj la malĝusta ofte venkas pro kialoj tute ne rilataj al la tunelo.

Kontrolu la sesion, poste la itineron

Kontrolu unue la interfacon, poste la itinerojn, poste unu celon, kiu gravas. Ĉiu paŝo havas sian propran malsukcesmanieron, kaj testi ĉiujn tri samtempe produktas konkludon, kiun vi poste ne povos defendi.

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

Se la publika kontrolo montras la adreson de la finpunkto dum privata celo tempolimas, la tunelo portas vian defaŭltan itineron kaj la fora flanko ne respondas pri tiu celo. Se la privata celo respondas sed la publika kontrolo ne ŝanĝiĝas, la profilo uzas dividitan tuneladon kaj nur parto de la trafiko uzas la sesion.

Tenu la tri fazojn apartaj

Aŭtentikigo, adresa intertraktado kaj plusendado malsukcesas malsame, kaj ĉiu havas alian posedanton. Akreditaĵoj estas identeca problemo, elĉerpiĝo de IPCP estas problemo de servila politiko, kaj mankanta revena itinero estas problemo de reta dezajno. Raporti ĉiujn tri kiel “la VPN estas difektita” garantias malrapidan riparon.

Notu la asignitan adreson, la basenon, el kiu ĝi venis, kaj ĉu la LAN laŭsupoze atingas ĝin. Tiu sola noto malhelpas al la sekva persono supozi DHCP-luon kaj serĉi gamon, kiu neniam estis implikita.