Този адрес на тунела е партньор, а не подмрежа, която можете да разглеждате

Клиентът ви се свързва и показва двойка адреси или един адрес с маска 255.255.255.255, и първата реакция е, че сървърът е дал нещо счупено. Нищо не е счупено: тунелният интерфейс е връзка точка-точка и маската описва далечния край на тази една връзка, а не диапазон от съседи. Четенето на двойката като локален адрес и партньор обяснява странната маска, маршрута до един хост до нея и липсващата таблица на съседите. Това, което същото четене не оправдава, е план за адреси, който се припокрива с офис мрежата.

Защо маската изглежда грешна при тунелна връзка

При Ethernet интерфейс адресът и маската твърдят две неща: този хост притежава адреса и всичко в префикса е пряк съсед. Ядрото извежда маршрут на връзката от тези два факта и след това разрешава адреси на връзката за съседите, които смята за налични. Интерфейс точка-точка запазва собствеността и изхвърля съседите, затова вторият адрес в реда на клиента е далечният край, а не друг хост в споделен сегмент. Няма хардуерно адресиране, няма трафик за разрешаване и няма широкомовен домейн, към който да се присъедините, поради което интерфейсът се държи като тръба с точно едно местоназначение.

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

Две топологии, две форми на адресите

По-старата топология точка-точка дава на всеки клиент малък блок и използва двата средни адреса, затова маската изглежда като фрагмент от мрежа, а не като пул. Топологията на подмрежата дава адрес от пула с маската на пула и назовава тунелния адрес на сървъра за партньор. И двете създават валидна връзка и се различават само по това кои адреси се появяват в профила и по маската, която потребителят вероятно ще постави под въпрос.

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

Когато пулът и офис мрежата претендират за едни и същи битове

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

Префиксите, които само изглеждат подобни, са друг случай и сравняването на октети на око не е сравнение на префикси. Изпишете двата и пребройте маскираните битове: 192.168.4.0/24 срещу 192.168.6.0/24 съвпадат до бит 22 и се разделят при бит 23, защото третият октет се чете 00000100 срещу 00000110, така че тези две мрежи са наистина отделни. Поставете 10.8.0.0/24 до друг 10.8.0.0/24 и всички 24 маскирани бита съвпадат, което означава, че един маршрут не може да изрази и двете места. Дължината на маската решава къде спира сравнението, а мрежата, инсталирана втора, губи.

Какво не може да достави маршрутизирана връзка

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

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

Четене на интерфейса, преди да редактирате профила

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

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

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