Чаму два сайты з адной падсеткай — не адна LAN

Дзве ўстановы абедзве выкарыстоўваюць 192.168.77.0/24, і нехта прапануе тунэль, каб яны сталі адной сеткай. Фраза гучыць проста і хавае тры розныя канструкцыі: дзве незалежныя LAN, якія сутыкаюцца, адзін наўмысны сегмент Ethernet, падоўжаны праз WAN, і схема proxy-ARP, якая адказвае за далёкія адрасы. Якая з іх у вас — вызначае, што хост робіць з пакетам, і адказ бачны да ўдзелу VPN-шлюза.

Хост вырашае раней за маршрутызатар

Хост з адрасам 192.168.77.10/24 параўноўвае атрымальніка са сваім прэфіксам. Усё ўнутры гэтага прэфікса знаходзіцца ў тым жа звёне, таму хост непасрэдна развязвае адрас канальнага ўзроўню атрымальніка. Усё па-за ім ідзе на шлюз па змаўчанні.

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

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

ARP — пытанне лакальнага звяна

ARP пытае, хто валодае адрасам у гэтым звене, і адказ павінен прыйсці ад чаго-небудзь, што чуе шырокавяшчальны запыт. Маршрутызатар на другім канцы тунэля IPsec не чуе яго, калі канструкцыя не зробіць два сайты адным шырокавяшчальным даменам.

Дзве прылады з адным адрасам робяць горш: нават паспяховае развязанне не скажа, якая з іх адказала.

Дубляванне адрасоў — не памылка маршрутызацыі, і ніякі маршрут гэтага не выправіць. Або сайты перанумароўваюцца ў розныя прэфіксы, або яны наўмысна становяцца адным канальным даменам.

Падоўжаны сегмент пераносіць кадры, а не маршруты

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

Тут далёкі шлюз зусім не маршрутызуе паміж двума аднолькавымі падсеткамі. Кадры праходзяць праз ніжні ўзровень, які сам маршрутызуе IP, а масты падаўжаюць размову Ethernet.

Кошт — большы радыус уражанасці. Затопліванне для невядомых атрымальнікаў, петлі, размеркаванне DHCP і ўнікальная адрасацыя — усё патрабуе аднаго плана на абодва сайты. Калі WAN падае, хасты губляюць трафік, які лічаць лакальным. Фільтраванне на мосце і правілы VLAN могуць абмежаваць тое, што перасякае, але перанос усё адно не гарантуе, што кожны лакальны кантрольны кадр дабярэцца.

Proxy ARP — трэцяя канструкцыя

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

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

Ён таксама не робіць адвольныя не-IP пратаколы маршрутызуемымі і не ўзнаўляе шырокавяшчальны дамен Ethernet. Выкарыстоўвайце яго, калі патрабаванне — менавіта такая замена, а не як кароткі шлях для адкладзенай перанумарацыі.

Выбірайце з патрабавання, потым праверце

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

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

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Вынік «у тым жа звене» з няўдалым запісам суседа паказвае на адсутны шлях канальнага ўзроўню. Вынік via называе шлюз і пераносіць пытанне ў маршрутызацыю. На мосце праверце базу перасылкі, каб убачыць, ці MAC быў вывучаны праз тунэль. Кожны вынік звужае пытанне канструкцыі, а не пачынае яго зноў.