pfSense як VPN-сервер і кліент: два шляхі, адзін маршрутызатар

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

Назвіце дзве ролі, перш чым кранаць якую-небудзь наладу

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

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

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

Трымайце адказы сервера на шляху WAN

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

Не дазваляйце зыходнаму тунелю з'есці ўласную канчатковую кропку

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Выберыце, якія карыстальнікі атрымаюць выхад

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

Вырашыце, што будзе, калі выхад адмовіць

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

Адключыце асобнік кліента, паглядзіце, да чаго падключаны карыстальнік яшчэ можа дабрацца, затым уключыце яго зноў. Запыт, які сканчаецца тайм-аўтам, — гэта вынік поўнага блакавання, які вы прасілі; той, што адказвае адрасам WAN, — гэта вяртанне, якое вы не дакументавалі. Паўтарыце праверку для IPv6 і для DNS, бо палітыка, напісаная для IPv4, нічога не кажа пра трафік AAAA, а рэзалвер, прасунуты любым з тунеляў, адказвае адтуль, адкуль запыт сапраўды выходзіць.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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