Чаму хост у лакальнай сетцы адпраўляе ARP для адраса кліента OpenVPN

Праблемы даступнасці паміж хостам у лакальнай сетцы і кліентам VPN часта вядуць да самога плана адрасацыі. Дайце гэтаму хосту інтэрфейс на 10.0.100.0/22, і ён будзе лічыць кожны адрас ад 10.0.100.0 да 10.0.103.255 падключаным непасрэдна, уключаючы пул кліентаў, ціха размешчаны на 10.0.101.0/24. Адказ ніколі не ідзе на маршрутызатар, бо з пункту гледжання хоста маршрутызатар не ўдзельнічае. Пакет адрасаваны суседу і запытваецца на провадзе.

Гэты механізм стаіць за цэлай сям'ёй паведамленняў: тунель узняты, у сервера ёсць маршрут, а хост у лакальнай сетцы ўсё яшчэ не можа дабрацца да кліента.

Прэфікс /22, які паглынае /24

Чытайце прэфікс як дыяпазон, а не як радок. Прэфікс /22 змяшчае 1024 адрасы, а 10.0.100.0/22 цягнецца ад 10.0.100.0 да 10.0.103.255, таму пул на 10.0.101.0/24 цалкам ляжыць унутры. Памылка перажывае праверку, бо першыя актэты пула выглядаюць інакш, чым першыя актэты лакальнай сеткі, і толькі трэці актэт выдае ўкладзенасць. Запішыце абодва дыяпазоны ў ліках, перш чым абвясціць іх асобнымі.

Тая ж укладзенасць можа праявіцца і ў адваротны бок. Пул, які выглядае свабодным, бо цяпер яго ніхто не выкарыстоўвае, усё ж можа трапіць у прэфікс, абвешчаны нейкім маршрутызатарам пляцоўкі, і план адрасацыі — адзіны дакумент, які гэта паказвае.

Прамое злучэнне азначае ARP, а не маршрутызацыю

Калі хост з інтэрфейсам /22 адпраўляе на 10.0.101.25, ядро параўноўвае атрымальніка з прэфіксам інтэрфейса і знаходзіць супадзенне. Пакет становіцца пошукам суседа, а не маршрутызаваным пакетам, а ў Ethernet пошук суседа — гэта ARP-запыт для гэтага адраса. Калі адрас належыць кліенту VPN за маршрутызаваным шлюзам, ніводзін хост у лакальнай сетцы ім не валодае, таму запыт застаецца без адказу, а пакеты адкідваюцца. Тунель не вінаваты, і кліент ніколі не бачыць трафік.

Таму збой выглядае асіметрычным і часам перарывістым. Хост VPN часта дастае лакальную сетку, бо яго ўласныя маршруты паказваюць у патрэбны бок, тады як хост у лакальнай сетцы не можа адказаць, і любое кэшаванне састарэлага запісу ARP прымушае сімптом мігцець.

TUN, TAP і што нясе кожны

Прылада TUN пераносіць IP-пакеты, а прылада TAP пераносіць кадры Ethernet. Маршрутызаванае злучэнне TUN не павінна пераносіць ARP, каб забяспечыць даступнасць IP, і менавіта таму запыт без адказу вышэй чаканы, а не зламаны. TAP з наўмысна настроеным мостам можа пашырыць шырокавяшчальны дамен і прымусіць ARP працаваць, але гэта змяняе тое, што бачыць кліент, патрабуе канцавых пунктаў з той жа інкапсуляцыяй і ёсць пераробкай сеткавай мадэлі, а не рамонтам прэфікса, які перакрываецца. Пераход з маршрутызаванага разгортвання на TAP дзеля выпраўлення памылкі плана адрасацыі мяняе малую праблему на большую.

Запішыце, дзе з'явіўся ARP-запыт і якая сістэма яго адправіла, перш чым рабіць высновы. Адпраўнік кажа вам, што ён думае пра атрымальніка, а не што робіць тунель.

Спраектуйце пул, які не можа перакрывацца

Выберыце пул па-за кожным падключаным прэфіксам і кожным абвешчаным прэфіксам пляцоўкі, потым дадайце маршруты, якія робяць яго дасягальным у абодва бакі. Дыяпазон накшталт 10.8.0.0/24 у невыкарыстанай частцы плана лёгка абдумаць, а лакальная сетка, якой трэба да яго дабрацца, атрымлівае статычны маршрут, які паказвае на сервер VPN. Змяняйце разам выдзяленне, абвешчаныя маршруты, дазволеныя адрасы крыніц і правілы брандмаўэра, бо яны апісваюць адзін праект, а не чатыры налады.

Source NAT на серверы можа схаваць пул за адрасам, маршрутызаваным з лакальнай сеткі, і гэта законны інструмент міграцыі. Ён таксама перапісвае крыніцу, таму лакальная сетка губляе магчымасць адносіць злучэнні да асобных кліентаў і прымяняць правілы для кліента.

Для прыёмкі выкарыстайце рэальна прызначаны адрас сапраўднага кліента і сапраўдны запыт праграмы з хоста ў лакальнай сетцы, потым пацвердзіце, што адказ ідзе праз запланаваны шлюз, а не па провадзе.