Šī L2TP adrese ir IPCP, nevis DHCP noma LAN tīklā
Iekšējā adrese nāk no PPP sarunām, nevis no biroja DHCP servera. Skatiet, kurš posms to piešķir, kāpēc LAN nevar atbildēt un kas jāpārbauda.
Savienojums paceļas un adapteris rāda adresi biroja diapazonā, tāpēc dabiskais secinājums ir, ka VPN jums deva LAN adresi un tādējādi ievietoja jūs LAN tīklā. Neviena no šīm divām pusēm nav pilnīgi pareiza. L2TP pārnēsā PPP sesiju, un PPP ar IPCP vienojas par iekšējo IPv4 adresi. Šī adrese ir sesijas parametrs, par ko vienojas divas puses, nevis biroja DHCP servera izsniegta noma, un tās turēšana nepadara jūs par kaimiņu uz biroja vada.
Divas adreses vienā savienojumā
L2TP savienojumā ir divas neatkarīgas sarunas. Ārējā izveido aizsargātu ceļu starp jūsu ierīci un VPN galapunktu pāri jebkuram jau esošajam tīklam. Iekšējā ir PPP sesija, un tieši tur tiek saskaņota jūsu sesijas adrese un otras puses adrese. Interneta trafiks var iziet pavisam citā adresē, galapunkta publiskajā adresē, tāpēc VPN pārbaudes lapa un adaptera adrese reti sakrīt.
Šo trīs lomu nošķiršana atbild uz lielāko daļu jautājumu, ko cilvēki atnes šim slānim. Privāts numurs VPN saskarnē ir normāli un gaidīti. Tas neko nesaka par to, vai galapunkts mainīja jūsu publisko izeju, un pats par sevi neizlemj, kurus galamērķus sasniedz jūsu trafiks.
Ko tieši dara IPCP
IPCP ir PPP IPv4 vadības protokols. Katra puse sūta Configure-Request ziņojumus, kas apraksta vēlamās opcijas, un adreses opcija ir viena no tām. Klients, kuram vēl nav adreses, parasti jautā ar 0.0.0.0, un serveris atbild ar Configure-Nak, kas nes adresi, kuru tas vēlas, lai klients izmantotu. Tad klients pieprasa šo adresi, un sesija paceļas ar lokālo un attālo adresi.
Šī apmaiņa ir dokumentēta PPP un IPCP specifikācijās, un tā izskaidro detaļu, kas izskatās pēc kļūdas: adresi serveris izvēlas pēc savas politikas, kas var būt baseins, iestatījums vienam lietotājam vai ar autentificēto identitāti saistīta adrese. Kad baseins ir izsmelts vai politika nonāk pretrunā ar pieprasījumu, autentifikācija var izdoties, kamēr adreses sarunas neizdodas, un klients ziņo par savienojumu, kas nekad nenostabilizējas.
ip addr show ppp0
ip route show default
dmesg | grep -i pppd
pppd žurnāla rinda, kurā nosaukta lokālā un attālā adrese, ir šo sarunu veiksmīgās beigas. Tās neesamība blakus veiksmīgai autentifikācijai norāda uz adreses posmu, nevis uz akreditācijas datiem.
Kāpēc LAN nevar jums atbildēt
Adrese no tālās puses diapazona rada gaidas, ka šī LAN tīkla resursdatori var jūs sasniegt, un pārsvarā nevar, ja vien serveris nenovirza jūsu sesijas adresi atpakaļ tunelī. Atrašanās baseinā ir apgalvojums par piešķiršanu, nevis par topoloģiju. Biroja failu serverim nav maršruta uz jūsu sesijas adresi, ja vien VPN serveris to nepārsūta, un varbūt tas pat nav atļauts, pat ja pārsūta.
Tāpēc arī pārklājošie diapazoni rada problēmas, kas nav samērojamas ar to šķietamo lielumu. Ja baseins pārklājas ar LAN tīklu, ko klients jau izmanto, klienta maršrutēšanas tabulā tagad ir divas prasības uz vienu un to pašu prefiksu, un nepareizā bieži uzvar tādu iemeslu dēļ, kuriem nav nekāda sakara ar tuneli.
Vispirms pārbaudiet sesiju, tad maršrutu
Vispirms pārbaudiet saskarni, tad maršrutus, tad vienu svarīgu galamērķi. Katram solim ir savs atteices veids, un visu trīs pārbaudīšana vienlaikus dod secinājumu, ko vēlāk nevarēsiet aizstāvēt.
curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20
Ja publiskā pārbaude rāda galapunkta adresi, kamēr privāts galamērķis beidzas ar noildzi, tunelis pārnēsā jūsu noklusējuma maršrutu un tālā puse uz šo galamērķi neatbild. Ja privātais galamērķis atbild, bet publiskā pārbaude nemainās, profils izmanto sadalīto tunelēšanu un sesiju izmanto tikai daļa trafika.
Turiet trīs posmus atsevišķi
Autentifikācija, adreses sarunas un pārsūtīšana neizdodas dažādi, un katram ir cits atbildīgais. Akreditācijas dati ir identitātes problēma, IPCP izsīkums ir servera politikas problēma, un trūkstošs atgriešanās maršruts ir tīkla projektēšanas problēma. Ziņot par visiem trim kā “VPN ir salūzis” garantē lēnu labojumu.
Pierakstiet piešķirto adresi, baseinu, no kura tā nāca, un vai LAN to ir jāsasniedz. Šī vienīgā piezīme neļauj nākamajam cilvēkam pieņemt DHCP nomu un meklēt apgabalu, kas nekad nav bijis iesaistīts.