NAT для LAN праз tun0 на VPN-шлюзе OpenBSD

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

Маршрутызацыя і перапісванне адказваюць на розныя пытанні

Табліца маршрутызацыі вырашае, што 172.20.0.0/16 дасягальны праз tun0, і гэтае рашэнне прымаецца да таго, як звяртаюцца да любой трансляцыі pf. Затым трансляцыя крыніцы змяняе загаловак пакета, каб аддалены бок бачыў адрас тунеля шлюза, а не хост LAN. Ні адзін механізм не замяняе іншы: правіла nat не можа стварыць маршрут з нічога, а маршрут не можа пераканаць аддалены маршрутызатар, які ніколі не чуў пра вашу прыватную падсетку. Калі ў аддаленага боку няма зваротнага шляху, адказы адкідаюцца або перасылаюцца на ягоны шлюз па змаўчанні, і ніякая настройка правілаў гэтага не выправіць.

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

Тры ўмовы, якія вызначаюць выбар

Задайце тры пытанні па парадку, і праект звычайна выбірае сябе сам. Ці мае аддаленая сетка статычны маршрут, які паказвае на адрас тунеля для 192.168.88.0/24, ці яе адміністратар кантралюе маршрутызатары на гэтым шляху? Калі так, дазвольце адрасам LAN ісці без змяненняў і цалкам прапусціце трансляцыю. Ці патрэбна вам бачнасць па кожным кліенце на аддаленым баку — для палітыкі доступу або для слядоў аўдыту? Калі так, захаванне крыніцы варта працы з маршрутызацыяй. Ці дастаткова стабільны адрас тунеля, каб запісаць яго ў аддалены маршрут, ці ён змяняецца паміж перападключэннямі?

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

Размясціце фрагмент так, каб pf сапраўды яго ацаніў

Фрагмент ніжэй мяркуе, што LAN — гэта 192.168.88.0/24, аддаленая сетка — 172.20.0.0/16, а інтэрфейс тунеля — tun0. Нішто ў ім не выбірае наступны крок. Ён толькі перапісвае крыніцу ў пакетах, якія ўжо выходзяць праз тунель.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Дзве дэталі ў першым радку нясуць асноўную вагу. Дужкі вакол tun0 кажуць pf чытаць адрас інтэрфейса кожны раз, калі ён будуе запіс стану, што важна, калі тунель перанумароўваецца пасля перападключэння. Слова match азначае, што правіла перапісвае і затым правальваецца далей, таму асобнае правіла pass усё яшчэ павінна дапусціць паток. Інтэрфейс, названы ў радку match, таксама павінен быць тым, які выбірае табліца маршрутызацыі, інакш pf ацэніць правіла на іншым выходным шляху, чым фактычна ідзе пакет.

Не забудзьце пра бок ядра. Перасылка IPv4 павінна быць уключана, а правілы pass са станам для тунеля і LAN павінны існаваць, перш чым усё гэта набудзе сэнс. Раздзел PF NAT у FAQ па OpenBSD — правільнае месца, каб зверыць парадак ключавых слоў.

Праверце набор правілаў, перш чым давяраць трафіку

Спачатку праверце сінтаксіс камандай pfctl -nf /etc/pf.conf, якая разбірае файл, не загружаючы яго. Затым загрузіце палітыку і прачытайце, што ядро фактычна трымае, бо правіла, якое чыста разабралася, усё яшчэ можа быць заслонена або прымацавана не да таго інтэрфейса. pfctl -sn друкуе правілы трансляцыі ў загружаным выглядзе, а pfctl -sr друкуе правілы фільтрацыі ў парадку ацэнкі.

Далей назірайце за дротам. На шлюзе tcpdump -ni tun0 'host 172.20.0.10' паказвае, ці адрас крыніцы, які пакідае тунель, — гэта адрас тунеля ці хост LAN. Хуткі netstat -rn -f inet пацвярджае, у які інтэрфейс развязаецца прызначэнне. Калі трафік пайшоў, pfctl -ss пералічвае запісы стану; калі паток не стварыў стану, пакет ніколі не супаў з правілам, якое яго стварае.

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

Калі трансляцыя каштуе больш, чым эканоміць

Трансляцыя хавае кліентаў, і часам гэта менавіта няправільны абмен. Сеткі, што перакрываюцца, — адзін выпадак: калі аддалены бок таксама выкарыстоўвае 192.168.88.0/24 унутры, прадстаўленне хастоў LAN як шлюза робіць калізію горш, а не лепш. Палітыкі IPsec, якія выбіраюць трафік па пары адрасоў, — іншы, бо база даных палітыкі бяспекі супастаўляецца да трансляцыі і ніколі не бачыць ваш перапісаны пакет. Любое разгортванне, якое выстаўляе рахункі, абмяжоўвае або аўдытуе па кожным карыстальніку, таксама губляе ідэнтычнасць, патрэбную яму ў той момант, калі крыніца зводзіцца да аднаго адраса.

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

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