Сайт да сайта супраць аддаленага доступу праз VPN: што звязвае кожны з іх

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

Два рашэнні, дзве мяжы

Ні адно з рашэнняў не пашырае шырокавяшчальны дамен LAN. Прылады на далёкім баку не з’яўляюцца ў лакальным спісе выяўлення, і чаканне ад іх гэтага — першае дапушчэнне, ад якога трэба адмовіцца. Прыватныя DNS-імены, якія вы публікуеце свядома, больш прадказальныя за любы пратакол выяўлення і перажываюць змену пастаўшчыка.

Вазьміце 10.10.0.0/24 на адным сайце і 10.20.0.0/24 на другім. Шлюзу A патрэбен маршрут або селектар трафіку, які накіроўвае прэфікс 10.20.0.0/24 у тунель, а шлюзу B патрэбна люстраная копія гэтага. Пасля гэтага хасты па абодва бакі выкарыстоўваюць звычайнае IP-злучэнне і ніколі не даведваюцца пра існаванне тунеля. Гэтая незаўважнасць і ёсць функцыяй, і менавіта таму збоі выглядаюць як звычайныя сеткавыя памылкі, а не як памылкі тунеля.

Палітыка і маршрут — гэта не адзін і той жа тунель

У разгортванні IPsec на аснове палітык узгодненыя селектары трафіку дакладна вызначаюць, якія пары крыніцы і прызначэння абараняюцца. Калі за адным шлюзам з’яўляецца новая падсетка і ніводны селектар яе не пакрывае, тунель застаецца ўзнятым, а новая падсетка проста не перадаецца. У рашэнні на аснове маршрутаў трафік атрымлівае інтэрфейс, а рашэнне прымае табліца маршрутызацыі, што робіць даданне прэфікса змяненнем маршруту, а не перамовамі тунеля.

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

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

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

Сплануйце адрасацыю да тунеля

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

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

Пытанне MTU таксама вырашыце загадзя. Тунель паменшвае карысную нагрузку, і рашэнне, якое спадзяецца на фрагментацыю, паводзіць сябе інакш, чым тое, што фіксуе MSS на шлюзах.

Перасылка і палітыка знаходзяцца па-за тунелем

Шлюз павінен быць гатовы перасылаць пакеты паміж інтэрфейсам тунеля і інтэрфейсам LAN, і абодва кірункі патрабуюць палітыкі, якая дазваляе сэрвіс. У Linux гэта два асобныя параметры, плюс правілы брандмаўэра, якія вырашаюць, ці дазволены перасланы паток наогул.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

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

Тэстуйце з хоста, а не са шлюза

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

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

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

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