Този адрес на L2TP е IPCP, а не наем на DHCP в LAN

Вътрешният адрес идва от преговори по PPP, а не от 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 и да търси обхват, който никога не е участвал.

Подобни статии