Ang L2TP address na iyon ay IPCP, hindi DHCP lease sa LAN

Bumangon ang koneksyon at nagpapakita ang adapter ng address sa saklaw ng opisina, kaya ang natural na konklusyon ay binigyan ka ng VPN ng LAN address at inilagay ka nito sa LAN. Wala sa dalawang hati niyon ang ganap na tama. L2TP nagdadala ng PPP session, at nakikipagnegosasyon ang PPP sa panloob na IPv4 address gamit ang IPCP. Ang address na iyon ay parameter ng session na napagkasunduan ng dalawang panig, hindi lease na ibinibigay ng DHCP server ng opisina, at ang pagkakaroon nito ay hindi ka ginagawang kapitbahay sa kable ng opisina.

Dalawang address sa isang koneksyon

May dalawang independiyenteng negosasyon sa isang L2TP connection. Ang panlabas ay nagtatatag ng protektadong landas sa pagitan ng iyong device at ng VPN endpoint sa anumang network na mayroon ka na. Ang panloob ay ang PPP session, at doon napagkasunduan ang address ng iyong session at ang address ng kabilang dulo. Maaaring lumabas ang internet traffic sa ilalim ng ikatlong address nang buo, ang pampublikong address ng endpoint, kaya bihirang magtugma ang pahina ng pagsusuri ng VPN at ang address ng adapter.

Ang paghihiwalay ng tatlong tungkuling iyon ay sumasagot sa karamihan ng tanong na dinadala ng mga tao sa layer na ito. Ang pribadong numero sa VPN interface ay normal at inaasahan. Wala itong sinasabi tungkol sa kung binago ng endpoint ang iyong pampublikong labasan, at hindi nito mag-isa tinutukoy kung aling destinasyon ang naaabot ng iyong traffic.

Ano ang eksaktong ginagawa ng IPCP

Ang IPCP ay ang IPv4 control protocol para sa PPP. Nagpapadala ang bawat panig ng Configure-Request na mensahe na naglalarawan ng mga opsyong gusto nito, at ang opsyong address ay isa sa mga iyon. Ang kliyenteng wala pang address ay karaniwang nagtatanong gamit ang 0.0.0.0, at sumasagot ang server ng Configure-Nak na nagdadala ng address na gusto nitong gamitin ng kliyente. Pagkatapos ay hinihiling ng kliyente ang address na iyon, at bumabangon ang session na may lokal at malayong address.

Ang palitan na iyon ay dokumentado sa PPP at IPCP specifications, at ipinapaliwanag nito ang detalyeng mukhang bug: pinipili ng server ang address ayon sa sarili nitong patakaran, na maaaring pool, setting bawat user, o address na nakatali sa na-authenticate na pagkakakilanlan. Kapag naubos ang pool, o sumalungat ang patakaran sa kahilingan, maaaring magtagumpay ang authentication habang nabigo ang address negotiation, at nag-uulat ang kliyente ng koneksyong hindi kailanman tumitigil.

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

Ang linyang pppd log na nagbabanggit ng lokal at malayong address ay ang matagumpay na wakas ng negosasyong iyon. Ang kawalan nito sa tabi ng matagumpay na authentication ay tumuturo sa yugto ng address, hindi sa mga kredensyal.

Bakit hindi ka masagot ng LAN

Ang address mula sa saklaw ng malayong panig ay lumilikha ng inaasahan na maaabot ka ng mga host sa LAN na iyon, at kadalasan ay hindi nila kaya maliban kung iruruta ng server ang address ng iyong session pabalik sa tunnel. Ang pagiging nasa loob ng pool ay pahayag tungkol sa paglalaan, hindi sa topolohiya. Walang ruta ang file server ng opisina patungo sa address ng iyong session maliban kung ipapasa ito ng VPN server, at maaaring hindi rin ito pinapayagan kahit na ipapasa.

Iyon din ang dahilan kung bakit ang magkakapatong na saklaw ay nagdudulot ng problemang hindi tugma sa nakikitang laki nila. Kung ang pool ay magkapatong sa LAN na ginagamit na ng kliyente, may dalawang pag-angkin na ngayon ang routing table ng kliyente sa parehong prefix, at madalas na nananalo ang mali dahil sa mga dahilang walang kinalaman sa tunnel.

Suriin ang session, pagkatapos ang ruta

Suriin muna ang interface, pagkatapos ang mga ruta, pagkatapos ang isang destinasyong mahalaga. May sariling paraan ng pagpalya ang bawat hakbang, at ang pagsuri sa tatlo nang sabay ay nagbibigay ng konklusyong hindi mo maipagtatanggol mamaya.

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

Kung ipinapakita ng pampublikong pagsusuri ang address ng endpoint habang nag-time out ang pribadong destinasyon, dinadala ng tunnel ang iyong default na ruta at hindi sumasagot ang malayong panig para sa destinasyong iyon. Kung sumasagot ang pribadong destinasyon pero hindi nagbabago ang pampublikong pagsusuri, gumagamit ang profile ng split tunneling at bahagi lamang ng traffic ang gumagamit ng session.

Panatilihing hiwalay ang tatlong yugto

Ang authentication, address negotiation, at forwarding ay pumapalya sa magkaibang paraan, at may iba’t ibang may-ari ang bawat isa. Ang mga kredensyal ay problema sa pagkakakilanlan, ang pagkaubos ng IPCP ay problema sa patakaran ng server, at ang nawawalang return route ay problema sa disenyo ng network. Ang iulat ang tatlo bilang “sira ang VPN” ay ginagarantiyahan ang mabagal na pag-aayos.

Itala ang ibinigay na address, ang pool na pinagmulan nito, at kung dapat itong maabot ng LAN. Ang nag-iisang tala na iyon ay pumipigil sa susunod na tao na ipalagay na DHCP lease ito at maghanap ng saklaw na hindi kailanman nasangkot.