Защо хост в LAN изпраща ARP за адреса на клиент на OpenVPN

Проблемите с достижимостта между хост в LAN и клиент на VPN често водят обратно към самия план за адресиране. Дайте на този хост интерфейс на 10.0.100.0/22 и той ще третира всеки адрес от 10.0.100.0 до 10.0.103.255 като директно свързан, включително пул от клиенти, тихо поставен на 10.0.101.0/24. Отговорът никога не отива към маршрутизатор, защото от гледна точка на хоста не участва никакъв маршрутизатор. Пакетът е адресиран до съсед и се изисква по кабела.

Този механизъм стои зад цяло семейство доклади: тунелът е активен, сървърът има маршрут, а хостът в LAN все още не може да достигне клиента.

Префиксът /22, който поглъща /24

Четете префикса като диапазон, а не като низ. Префикс /22 съдържа 1024 адреса, а 10.0.100.0/22 обхваща от 10.0.100.0 до 10.0.103.255, така че пул на 10.0.101.0/24 лежи изцяло вътре. Грешката преживява прегледа, защото първите октети на пула изглеждат различно от първите октети на LAN и само третият октет разкрива вложеността. Запишете двата диапазона с числа, преди да ги обявите за отделни.

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

Директната връзка означава ARP, а не маршрутизация

Когато хост с интерфейс /22 изпраща към 10.0.101.25, ядрото сравнява дестинацията с префикса на интерфейса и намира съвпадение. Пакетът става търсене на съсед вместо маршрутизиран пакет, а в Ethernet търсенето на съсед е ARP заявка за този адрес. Ако адресът принадлежи на клиент на VPN зад маршрутизиран шлюз, никой хост в LAN не го притежава, затова заявката остава без отговор и пакетите се отхвърлят. Тунелът не е виновен и клиентът никога не вижда трафика.

Затова отказът изглежда асиметричен и понякога прекъсван. Хостът на VPN често достига LAN, защото собствените му маршрути сочат в правилната посока, докато хостът в LAN не може да отговори, и всичко, което кешира остарял ARP запис, кара симптома да трепти.

TUN, TAP и какво носи всяко

Устройство TUN пренася IP пакети, а устройство TAP пренася Ethernet кадри. Маршрутизирана TUN връзка не е нужно да пренася ARP, за да осигури достижимост на IP, и точно затова заявката без отговор по-горе е очаквана, а не повредена. TAP с умишлено настроен мост може да разшири домейна за излъчване и да накара ARP да работи, но променя какво вижда клиентът, изисква крайни точки със същото капсуловане и е преработка на мрежовия модел, а не поправка за припокриващ се префикс. Превключването на маршрутизирано внедряване към TAP, за да се излекува грешка в плана за адресиране, заменя малък проблем с по-голям.

Отбележете къде се появи ARP заявката и коя система я изпрати, преди да правите изводи. Подателят ви казва какво мисли за дестинацията, а не какво прави тунелът.

Проектирайте пул, който не може да се припокрие

Изберете пул извън всеки свързан префикс и всеки обявен префикс на обект, след което добавете маршрутите, които го правят достижим в двете посоки. Диапазон като 10.8.0.0/24 в неизползвана част от плана е лесен за обмисляне, а LAN, който трябва да го достигне, получава статичен маршрут, сочещ към сървъра на VPN. Променяйте заедно разпределението, обявените маршрути, разрешените адреси на източника и правилата на защитната стена, защото те описват един проект, а не четири настройки.

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

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