Чаму ваша публічная служба Linux адказвае праз VPN

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

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

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

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

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

Што ядро насамрэч маршрутызуе: адрас крыніцы

Патрэбная вам зачэпка — гэта лакальны адрас, які служба выкарыстоўвае для адказаў. На хосце з ілюстрацыйным адрасам eth0 192.0.2.10/24 і шлюзам 192.0.2.1 гэты адрас прысутнічае на інтэрфейсе. На хмарнай ВМ публічны адрас можа быць трансляваны вышэй і адсутнічаць у госці, таму выкарыстоўвайце адрас, які хост насамрэч мае.

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

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

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

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

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Выкарыстоўвайце сапраўдны прэфікс і шлюз, а не капіюйце прыклад. Хмарны інтэрфейс, наладжаны як /32 са шлюзам на лініі, патрабуе іншага злучанага маршруту, а табліца, пабудаваная з няправільнага прэфікса, памыляецца на першым кроку. Атрыбут src паказвае пераважную крыніцу для гэтага маршруту; ён не замяняе правіла крыніцы.

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

Праверце пошукам з указаннем крыніцы

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

ip -4 route get 198.51.100.25 from 192.0.2.10

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

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

Дзе гэтае выключэнне спыняецца

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

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

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

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