Тунелът съобщава, че е свързан, иконата е зелена, а нищо в домашната локална мрежа не отговаря. Това е най-честата жалба за отдалечен достъп до FRITZ!Box и почти никога не е самият тунел. Планът за адресиране, идентичността на подмрежата или таблицата с маршрути на клиента е грешна. Кое от тях ще отстранявате, зависи от това дали сте избрали WireGuard, или по-стария IPSec Fernzugang, затова започнете с това да знаете кой точно сте конфигурирали.

Тунелът се вдига, а локалната мрежа мълчи

Тунел, който се установява, доказва, че ключовете и крайната точка са правилни. Той не доказва, че клиентът е получил адрес, към който кутията може да маршрутизира, нито че клиентът знае кои префикси принадлежат на тунела. Това са два отделни успеха и само вторият ви позволява да стигнете до принтер.

Проверете първо адреса на клиента, после таблицата му с маршрути.

Ако зададеният адрес е извън подмрежата на локалната мрежа, кутията няма към какво да маршрутизира обратно. Ако е вътре в диапазона на DHCP, кутията може да даде същия адрес на локално устройство. И двете дават тунел, който се свързва, и локална мрежа, която ви игнорира.

Какво всъщност конфигурира всяка опция

Опцията IPSec генерира конфигурационен файл за един потребител, съдържащ предварително споделения ключ и адресирането. Импортирате го в клиент, който говори същия профил, а под Windows това обикновено означава инструмента на производителя, а не вградения клиент. Опцията WireGuard генерира peer за едно устройство: двойка ключове, адрес вътре в тунела и крайна точка.

Тази разлика определя модела ви за поддръжка. Всяко устройство с WireGuard е отделен peer със свой ключ, затова отнемането на изгубен телефон означава изтриване на един peer, докато останалите продължават да работят. IPSec отнема чрез смяна на споделената тайна или конфигурацията на потребителя, което е по-грубо и засяга всяко устройство, което я използва.

Нито една от опциите не е остаряла. Пътят през IPSec остава поддържаният там, където отсрещната страна не може да пуска WireGuard.

Полетата на IPSec, които дават мъртъв тунел

Четири стойности трябва да съвпадат с локалната ви мрежа и три от тях се провалят по начин, който изглежда като счупен тунел.

ValueWhat breaks when it is wrong
LAN subnetThe client routes nothing, or routes the wrong prefix
Network addressThe configuration looks valid and the tunnel never establishes
DHCP rangeNo address is left to assign to tunnel clients
DNS serverThe tunnel works and name resolution does not

Мрежовият адрес е този, който подвежда хората. Подмрежата се идентифицира с първия си адрес, който обикновено завършва на нула, а въвеждането на адрес на хост там дава конфигурация, която изглежда напълно правдоподобна и никога не се свързва. Диапазонът на DHCP е важен по друга причина: клиентите на тунела обикновено получават адреси над него, затова диапазон, който заема цялата подмрежа, не оставя нищо за раздаване.

Припокриващите се подмрежи са другият класически случай. Ако отдалечената мрежа, към която се присъединявате, използва същия префикс като мрежата, на която седите, маршрутизирането не може да ги различи и преномерирането на едната страна е единственото истинско решение. Никакво количество клиентска конфигурация не го решава.

Защо WireGuard се проваля по друг начин

WireGuard няма предварително споделен ключ, който да се сбърка при въвеждане, затова отказите му се групират около дефиницията на peer. Списък с разрешени IP адреси, който пропуска префикса на локалната мрежа, дава тунел, който не носи нищо, защото клиентът никога не изпраща в него трафик, насочен към локалната мрежа. Остарял публичен ключ от която и да е страна дава ръкостискане, което никога не завършва. Липсваща крайна точка или грешен порт дават тишина, а не грешка.

Сравнете двете страни поле по поле, вместо да импортирате файла отново и да се надявате.

Единственият общ отказ е сблъсъкът на подмрежи. WireGuard с удоволствие ще построи тунел към мрежа, която се припокрива с вашата локална, и тогава таблицата с маршрути решава кой от двата еднакви префикса печели.

Докажете го отвън, после запазете път обратно навътре

Тествайте от мобилна връзка, никога отвътре в локалната мрежа, защото отвътре тествате път, който изобщо не включва тунела. Запишете кой порт използва всяка опция, преди да я включите, и пренасочете този порт към кутията.

Пазете генерирания файл някъде, където стигате без тунела, и междувременно запишете външното име на кутията.

Конфигурация, която никога не е тествана отвън, е план, а не работещ път за отдалечен достъп. Тествайте един хост в локалната мрежа по адрес, а не по име, за да не се обърка отказ на DNS с отказ на маршрутизиране.

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