Праз VPN — толькі адна вэб-служба лакальнага хоста, выбар па порце

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

Праверце тры ўмовы перад напісаннем правіла

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

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

Супастаўляйце адказ, а не порт прызначэння кліента

Адказ ад сервера, які слухае TCP 443, пакідае хост з портай-крыніцай 443. Браўзер на тым жа хосце, які падключаецца да аддаленага сайта HTTPS, дасылае эфемерную порту-крыніцу і порт прызначэння 443. Абодва — трафік порта 443, і толькі адзін з іх павінен выкарыстоўваць табліцу WAN, таму супастаўленне па порце прызначэння захапіла б не тую палову.

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

Пабудуйце поўную табліцу вяртання, перш чым правіла будзе на яе спасылацца

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

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Чытайце лічбы з жывога хоста, а не капіюйце іх. ip -4 rule show паказвае, якія прыярытэты занятыя, а даданне правіла на ўжо існуючы прыярытэт маўкліва змяняе парадак двух правілаў, якія паасобку выглядаюць цудоўна.

Сапраўдную працу тут робяць два селектары. iif lo — гэта тое, як ядро паведамляе пра пакеты, створаныя самім хостам, таму правіла не можа выпадкова захапіць перанакіраваны трафік, што прыходзіць звонку. ipproto tcp sport 443 звужвае яго да аднаго транспарту і адной порты — настолькі строга, наколькі дазваляе патрабаванне. Прыбярыце селектар пратакола, і правіла таксама зловіць UDP 443, а гэта іншая служба з іншымі паводзінамі.

Трымайце прыватныя адказы ўнутры тунэля

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

ip -4 route add table 100 throw 10.90.0.0/24

Маршрут throw спыняе пошук у гэтай табліцы і вяртае пакет спісу правілаў, таму палітыка VPN, што ідзе далей, атрымлівае свой шанец. Ён сам нічога не накіроўвае ў тунэль, і калі ні адно наступнае правіла не мае адпаведнага маршруту, пакет усё роўна праваліцца; праверце наступную палітыку, замест таго каб лічыць throw выпраўленнем.

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

Праверце TCP, затым QUIC, затым перазагрузку

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

HTTP/3 падаецца праз UDP і не будзе супастаўлены правілам TCP, таму слухачу QUIC патрэбен уласны селектар, інакш ён працягне выкарыстоўваць тунэль, пакуль HTTPS працуе. Захоўвайце тыя правілы, на якіх вы спыніцеся, у кампаненце, які валодае інтэрфейсам, і пацвярджайце іх пасля перападключэння або аднаўлення DHCP. Калі канкуруючы менеджар выдаляе маршрут часу выканання пасля перазагрузкі, гэта праблема ўладання, якую трэба вырашаць у крыніцы, а не падстава дадаваць шырэйшыя правілы NAT зверху.