Аднабаковы трафік пасля адключэння SNAT падсеткі Tailscale

Адключыце зыходны NAT на маршрутызатары падсеткі Tailscale, і тунель працягвае працаваць, а злучэнні праз яго спыняюцца. Запыты прыходзяць да пункта прызначэння з уласным адрасам аддаленага кліента ў накладзенай сетцы, што і ёсць сэнс змены, і адказам цяпер патрэбны шлях, пра які LAN ніколі не павінна была ведаць. Без гэтага шляху пакеты прызямляюцца, адказы сыходзяць праз звычайны шлюз, і збой выглядае як праблема брандмаўэра, якую не тлумачыць ніводнае яго правіла. Тунель спраўны; зваротнага шляху няма.

Што хаваў SNAT

Калі SNAT уключаны, маршрутызатар перапісвае адрас крыніцы на ўласны адрас LAN перад перадачай у падсетку, таму пункт прызначэння адказвае вузлу, да якога ўжо ведае дарогу, і больш нічога не трэба наладжваць. Адключэнне захоўвае зыходную крыніцу, і пункт прызначэння бачыць адрас у дыяпазоне накладзенай сеткі, а не суседа на ўласным дроце. Гэты адрас сапраўдны і маршрутызуемы праз tailnet, але з LAN праз шлюз па змаўчанні ён недасяжны. Дакументаваны перамыкач — --snat-subnet-routes=false, які ўжываецца да самога маршрутызатара падсеткі Linux.

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

Дзе можа знаходзіцца зваротны шлях

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

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

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

Чытанне збою як аднабаковага трафіку

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

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

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Ці варты сапраўдны адрас маршруту

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

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

Брандмаўэр, журналы і падвоеная роля

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

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

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