Адна і тая ж падсетка з абодвух бакоў: прывяжыце аддаленую LAN да свабоднага дыяпазону

Дом і офіс абодва выкарыстоўваюць 192.168.1.0/24, таму запыт да 192.168.1.1 мае два магчымыя адказы, і кліент выбірае адзін, не пытаючыся. Перанумарацыя працоўнай офіснай сеткі рэдка бывае папулярнай, а адрасы маршрутызатара часта ўбудаваныя ў прынтары, камеры і дакументацыю. Суаднясенне адрасоў на баку кліента можа замест гэтага паказаць аддаленую сетку ў свабодным дыяпазоне, і частка хаста можа застацца той жа, так што 192.168.1.20 выглядае як 10.203.41.20. Зачэпка ў тым, што гэта рэалізуюць толькі некаторыя кліенты, і для зваротнага шляху яно не робіць нічога.

Два погляды на адзін хост

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

Лакальныя прылады дома захоўваюць свае адрасы 192.168.1.x, і ў гэтым сутнасць практыкавання. Прынтар у суседнім пакоі застаецца даступным, пакуль офіс паказваецца ў дыяпазоне, які не канфліктуе.

Парадак аргументаў — гэта ўся хітрасць

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

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

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

Суаднясенне не стварае зваротнага шляху

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

Правілы на баку сервера павінны апісваць адрасы, якія існуюць на серверы пасля трансляцыі, а не бачны кліенту дыяпазон. Капіраванне псеўданіма ў правіла дазволу марнуе паўдня, бо ні адзін пакет на тым баку яго не нясе.

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

Імёны і карысная нагрузка перажываюць трансляцыю

Імя хаста, якое разрозніваецца ў сапраўдны 192.168.1.20, накіроўвае браўзер на лакальную прыладу замест аддаленай, незалежна ад таго, што кажа табліца маршрутызацыі. Адказ прыватнага DNS павінен паказваць на бачны кліенту дыяпазон, а сертыфікат TLS па-ранейшаму нясе імя, якое чакае праграма. Тэстуйце па імені, а не па адрасе, бо адрас можа працаваць, пакуль імя ціха разрозніваецца ў няправільным кірунку. Калі аддалены шлюз таксама абслугоўвае гэтую зону, яго ўласныя запісы таксама патрабуюць бачнага кліенту дыяпазону.

Перанакіраванні, убудаваныя URL-адрасы і праграмы, якія выдаюць уласны адрас у карыснай нагрузцы, могуць ламацца так, што ніякае суаднясенне пакетаў не выправіць. Стаўцеся да гэтага як да праблемы праграмы і ацэньвайце намаганні адпаведна, перш чым абяцаць, што перанумарацыя непатрэбная.

Тры праверкі перад тым, як узяць абавязацельства

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

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

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