Зошто хост во 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, потоа потврдете дека одговорот оди по планираниот портал, а не по жицата.