Та L2TP адреса је IPCP, а не DHCP закуп на LAN-у

Веза се успоставља и адаптер приказује адресу из опсега канцеларије, па је природан закључак да вам је VPN дао LAN адресу и тиме вас ставио на LAN. Ниједна од те две половине није сасвим тачна. L2TP носи PPP сесију, а PPP преговара унутрашњу IPv4 адресу помоћу IPCP-а. Та адреса је параметар сесије договорен између две стране, а не закуп који издаје DHCP сервер канцеларије, и њено држање вас не чини комшијом на канцеларијској жици.

Две адресе у једној вези

У L2TP вези постоје два независна преговора. Спољашњи успоставља заштићену путању између вашег уређаја и VPN одредишта преко било које мреже коју већ имате. Унутрашњи је PPP сесија и у њему се договарају адреса ваше сесије и адреса друге стране. Интернет саобраћај може излазити под потпуно трећом адресом, јавном адресом одредишта, због чега се страница за проверу VPN-а и адреса адаптера ретко поклапају.

Раздвајање те три улоге одговара на већину питања која људи доносе на овај слој. Приватан број на VPN интерфејсу је нормалан и очекиван. Он не говори ништа о томе да ли је одредиште променило ваш јавни излаз, и сам по себи не одлучује до којих одредишта стиже ваш саобраћај.

Шта IPCP тачно ради

IPCP је IPv4 контролни протокол за PPP. Свака страна шаље Configure-Request поруке које описују опције које жели, а опција адресе је једна од њих. Клијент који још нема адресу обично пита са 0.0.0.0, а сервер одговара Configure-Nak поруком која носи адресу коју жели да клијент користи. Затим клијент тражи ту адресу и сесија се подиже са локалном и удаљеном адресом.

Та размена је документована у PPP и IPCP спецификацијама и објашњава детаљ који изгледа као грешка: адресу бира сервер према сопственој политици, која може бити базен, подешавање по кориснику или адреса везана за аутентификовани идентитет. Када се базен исцрпи или се политика сукоби са захтевом, аутентификација може успети док преговор о адреси не успе, а клијент пријављује везу која се никада не смири.

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

Линија у pppd дневнику која наводи локалну и удаљену адресу је успешан крај тог преговора. Њено одсуство, поред успешне аутентификације, упућује на фазу адресе, а не на акредитиве.

Зашто вам LAN не може одговорити

Адреса из опсега далеке стране ствара очекивање да вас домаћини на том LAN-у могу достићи, а углавном не могу, осим ако сервер усмерава адресу ваше сесије назад у тунел. Бити унутар базена је изјава о додели, не о топологији. Канцеларијски сервер датотека нема путању до адресе ваше сесије осим ако је VPN сервер прослеђује, а можда то није ни дозвољено чак и ако је прослеђује.

Зато и опсези који се преклапају стварају проблеме несразмерне њиховој привидној величини. Ако се базен преклапа са LAN-ом који клијент већ користи, табела рутирања клијента сада има два захтева на исти префикс, а погрешан често побеђује из разлога који немају везе са тунелом.

Прво проверите сесију, затим путању

Прво проверите интерфејс, затим путање, затим једно одредиште које је важно. Сваки корак има свој начин неуспеха, а тестирање сва три одједном даје закључак који касније не можете одбранити.

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

Ако јавна провера показује адресу одредишта док приватно одредиште истиче, тунел носи вашу подразумевану путању и далека страна не одговара за то одредиште. Ако приватно одредиште одговара, али се јавна провера не мења, профил користи подељено тунелирање и само део саобраћаја користи сесију.

Држите те три фазе одвојено

Аутентификација, преговор о адреси и прослеђивање не успевају на различите начине, и свака има другог власника. Акредитиви су проблем идентитета, исцрпљеност IPCP-а је проблем серверске политике, а недостајућа повратна путања је проблем дизајна мреже. Пријавити сва три као „VPN је покварен“ гарантује споро решење.

Запишите додељену адресу, базен из којег је дошла и треба ли LAN да је достигне. Та једна белешка спречава следећу особу да претпостави DHCP закуп и тражи опсег који никада није био укључен.