Як даць адной тэставай LAN уласны выхад праз WireGuard

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

Вызначце, дзе жыве выхад

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

Прастора імёнаў або ВМ каштуе памяці і дае чысты радыус паражэння. Маршрутызацыя па палітыцы каштуе два правілы і пакідае вам адну скрынку для адладкі.

Выберыце выхад, які дазваляе вашу крыніцу

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

Пацвердзіце ў аператара тры рэчы: партнёр дазваляе адрас вашага тунеля, ён перасылае IPv4, а не завяршае на сабе, і ён прымяняе NAT на выхадзе. Без першага вашыя пакеты прыходзяць і знікаюць. Без трэцяга яны сыходзяць з прыватнай крыніцай і гінуць на наступным кроку. Затым праверце, што wg-quick не ўсталёўвае ўласную стандартную маршрутку — гэта прадухіляе Table = off; гэтая налада падаўляе стварэнне маршрутаў, а не праверкі AllowedIPs у партнёра і не яго працу з DNS.

Кіраванне робяць два аб'екты палітыкі

Для кіравання патрэбныя табліца і правіла. Табліца трымае два маршруты: прэфікс LAN з LAN-інтэрфейса і стандартны маршрут з тунеля. Правіла накіроўвае трафік, які прыходзіць на LAN-інтэрфейс і нясе гэты прэфікс, у табліцу. Выкарыстоўвайце селектар iif разам з супадзеннем крыніцы, бо ўласныя пакеты WireGuard шлюза ўзнікаюць лакальна і ніколі не супадаюць з уваходным інтэрфейсам.

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

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

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Закрыйце шчыліну адкату, перш чым яе адкрыць

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

Фільтр завяршае карціну. У куку forward прымайце кірунак з LAN у тунель для тэставага прэфікса і ўсталяваны зваротны кірунак, а затым адкідайце ўсё астатняе; NAT для гэтага прэфікса на тунельны інтэрфейс ідзе ў postrouting. Менавіта пакінуты policy drop на ланцугу перасылкі ператварае адсутную маршрутку ў цішыню, а не у ўцечку. Фільтраванне зваротнага шляху патрабуе свабоднага рэжыму на тунельным інтэрфейсе, бо публічная крыніца, што прыходзіць пасля дэкапсуляцыі, мае лепшы зваротны маршрут на баку WAN. Linux бярэ большае з значэнняў all і для інтэрфейса, таму налада тунельнага інтэрфейса не тое ж самае, што аслабленне праверкі паўсюль.

Давядзіце гэта выпадкам збою

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

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