VPN-кліент з адрасам LAN не знаходзіцца ў LAN
Калі выдаць VPN-кліенту адрас LAN, ён не трапляе ў гэты сегмент. Лакальныя хосты пытаюцца суседа, таму шлюз павінен адказаць, інакш адказ ніколі не дайдзе.
Кліент падключаецца, атрымлівае 10.50.0.200 і не можа дасягнуць сервера па 10.50.0.20, хоць абодва нумары знаходзяцца ў адной /24. За такой канфігурацыяй стаіць перакананне, што адрас з прэфікса LAN робіць кліента часткай LAN. Гэта не так. Кліент знаходзіцца на кропка-кропкавым злучэнні, сервер лічыць пункт прызначэння лакальным, а не хапае адказу суседа, якога ніхто не дасылае.
Міф: аднолькавы прэфікс азначае адзін сегмент
Прэфікс адраса паведамляе хосту, якія пункты прызначэння ён можа дасягнуць напрост, а якія патрабуюць маршрутызатара. Ён не кажа хосту, як пункт прызначэння фізічна далучаны, і ўжо тым больш не гарантуе, што пункт прызначэння можа адказаць на запыт канальнага ўзроўню. Гэта розныя пытанні, на якія адказваюць розныя табліцы на хосце. Маска адказвае на першае, табліца суседзяў на другое, і толькі першае знаходзіцца ў вашым кіраванні з боку VPN.
Калі сервер дасылае на 10.50.0.200, ён параўноўвае пункт прызначэння з уласнай маскай, лічыць адрас on-link і пытае лакальны сегмент пра апаратны адрас, які яму належыць. Гэты запыт выходзіць праз інтэрфейс Ethernet, а VPN-кліента там няма, каб яго пачуць.
Нішто ў канфігурацыі кліента не можа выправіць гэта з яго боку. Шлях адказу залежыць ад таго, што прылада ў LAN адкажа за кліента, або ад таго, што кліент мае адрас, які сервер не лічыць лакальным.
Што лакальны хост насамрэч робіць з адрасам
Паводзіны лёгка назіраць, і гэта варта зрабіць перад любымі зменамі. Пасля спробы дасягнуць кліента паглядзіце на хосце LAN у табліцу суседзяў: няпоўны або няўдалы запіс — гэта ўвесь дыягназ у адным радку. Гэты радок таксама паведамляе, што няспраўнасць лакальная для сегмента, а не дзесьці ўнутры тунеля.
ip neigh show 10.50.0.200 ip route get 10.50.0.200 arping -I eth0 -c 3 10.50.0.200
Пошук маршруту пакажа пункт прызначэння як on-link праз інтэрфейс Ethernet, і гэта менавіта праблема. Калі запіс суседа застаецца няпоўным, пакуль VPN-сесія актыўная, вы пацвердзілі, што не хапае развязання на канальным узроўні, а не маршрутызацыі ці палітыкі файрвола.
Правядзіце тую ж праверку з хоста ў іншай падсетцы і параўнайце. Хост, які дасягае кліента праз маршрутызатар, зусім не патрабуе запісу суседа, і гэтая розніца — гэта рашэнне праекта ў мініятуры.
Як Proxy ARP забяспечвае наступны крок
Proxy ARP прымушае шлюз адказваць на запыт канальнага ўзроўню за пункт прызначэння, да якога ён можа дабрацца праз іншы інтэрфейс. Хост LAN атрымлівае апаратны адрас, дасылае кадр на шлюз, і шлюз перасылае пакет у VPN-сесію. З пункту гледжання хоста кліент проста выглядае як размешчаны за шлюзам. У канфігурацыі кліента нічога не змяняецца.
Дакументацыя RouterOS па ARP ад MikroTik апісвае такое ўжыванне для кліентаў, якія падключаюцца па тэлефоне і пазычаюць адрасную прастору падключанага LAN. Механізм выпраўляе развязанне суседзяў, і ён працуе, бо шлюз сапраўды знаходзіцца на абодвух шляхах.
Гэта не тое ж самае, што падключыць кліента да LAN праз мост. Шлюз па-ранейшаму павінен перасылаць пакет у правільную актыўную сесію, а яго маршрутызацыя і палітыка файрвола па-ранейшаму павінны дазваляць сэрвіс. Proxy ARP змяняе, хто адказвае на запыт суседа, а не хто мае права размаўляць.
Уважліва чытайце назвы рэжымаў платформы. RouterOS адрознівае proxy-arp ад local-proxy-arp, і другі апрацоўвае трафік, які ўваходзіць і выходзіць праз той самы інтэрфейс. Гэта не ўзаемазаменныя напісанні, і ўключаць абодва без роздуму — не кароткі шлях.
Чаго Proxy ARP вам не дае
Ён не забяспечвае выяўленне праз broadcast або multicast. Кліент, якому трэба знайсці сэрвіс праз broadcast, усё роўна пацярпее няўдачу, бо шлюз перасылае unicast у сесію і не робіць кліента ўдзельнікам broadcast-дамена LAN. Пратаколы выяўлення, якія спадзяюцца на broadcast, — частая крыніца паведамленняў «для аднаго працуе, для другога не» ў праектах з пазычанымі адрасамі.
Ён не рэзервуе адрас. Калі пазычаны нумар таксама знаходзіцца ў пуле DHCP або ў статычным прызначэнні, дзве прылады могуць атрымаць адзін і той жа адрас, і выніковыя паводзіны залежаць ад часу. Паспяховы ўваход — гэта не рэзерваванне.
І ён не здымае неабходнасць узгаднення з уладальнікам LAN. Запіс Proxy ARP, які здзівіць уладальніка плана адрасоў, — гэта інцыдэнт падтрымкі, які чакае спакойнага тыдня.
Параўнанне з асобным маршрутызаваным пулам
Альтэрнатыва — даць VPN-кліентам уласны прэфікс і дазволіць хостам LAN маршрутызаваць да яго. Тады сервер дасылае off-link адказы на свой шлюз, шлюз маршрутызуе прэфікс да канчатковага пункта VPN, і развязанне суседзяў на сегменце LAN наогул не патрэбна. Гэта менш рухомых частак, чым пазычаны адрас плюс адказ proxy.
Такі праект лягчэй абдумаць і лягчэй праверыць, бо дыяпазон кліентаў бачна аддзелены ад дыяпазону LAN. Ён каштуе маршрут, зваротны шлях і правіла доступу — тыя ж рэчы, якія праект proxy ARP патрабуе ў менш відавочным месцы.
Выбірайце паміж мадэлямі свядома, а не выпадкова. Proxy ARP рамантуе адну канкрэтную ўзаемасувязь; маршрутызаваны пул пазбаўляе ад неабходнасці гэтага рамонту. Запішыце, што вы выбралі і чаму, і наступнаму чалавеку не давядзецца пераадкрываць гэта з няўдалага запісу суседа.