Перейти к содержимому
RU

Главная / Блог / Правила и маршрутизация

Раздельное туннелирование на практике — корпоративная сеть, локальный доступ и зарубежный прокси вместе

Правила и маршрутизация2026-07-171165 слов3 мин чтения
Раздельное туннелирование на практике — корпоративная сеть, локальный доступ и зарубежный прокси вместе

Классическая ситуация удалённой работы: внутренние системы компании должны идти через VPN, локальные сайты — напрямую, а зарубежным сервисам нужен прокси. Всё три одновременно и без того, чтобы одно мешало другому.

Вот конфигурация, которая это делает.

Сначала три класса трафика

Куда должен идти каждый классКорпоративная сетькадровые системы, GitLab, внутренние API, бастион-хосты Локальный интернетместный поиск, магазины, видео, платежи — напрямую, чтобЗарубежные сервисысайты документации, сервисы для разработчиков, иностранн
Определяются они по-разному: корпоративная сеть по домену плюс диапазону IP, локальные по GEOIP, зарубежные по перехвату остатка

Сложность в том, что корпоративные домены обычно резолвятся в приватные IP, но сами имена ничем не отличаются от публичных. Судить по одному GEOIP значит ошибаться.

Полная конфигурация

Шаг 1: определить группы политик

proxy-groups:
  - name: "🚀 Зарубеж"
    type: select
    proxies: ["♻️ Авто", "🇭🇰 Гонконг", "🇯🇵 Япония", "🇺🇸 США"]

  - name: "♻️ Авто"
    type: url-test
    include-all: true
    exclude-filter: "(?i)remaining|expiry|website"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "🏢 Корпоративная сеть"
    type: select
    proxies: [DIRECT]        # выходит через локальный интерфейс (VPN уже поднят)

  - name: "🇨🇳 Локально напрямую"
    type: select
    proxies: [DIRECT, "🚀 Зарубеж"]   # можно переключить при необходимости

  - name: "🐟 Прочее"
    type: select
    proxies: ["🚀 Зарубеж", DIRECT]

Сделать корпоративную сеть и локальный доступ группами политик, а не писать DIRECT прямо в правилах, значит иметь возможность переключить их в интерфейсе во время диагностики, ничего не редактируя.

Шаг 2: правила корпоративной сети (первыми в списке)

rules:
  # ===== 1. loopback и приватные диапазоны =====
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,🏢 Корпоративная сеть,no-resolve
  - IP-CIDR,10.0.0.0/8,🏢 Корпоративная сеть,no-resolve
  - IP-CIDR,172.16.0.0/12,🏢 Корпоративная сеть,no-resolve
  - IP-CIDR,100.64.0.0/10,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve

  # ===== 2. корпоративные домены =====
  - DOMAIN-SUFFIX,mycompany.com,🏢 Корпоративная сеть
  - DOMAIN-SUFFIX,corp.internal,🏢 Корпоративная сеть
  - DOMAIN-SUFFIX,intra,🏢 Корпоративная сеть
  - DOMAIN-KEYWORD,gitlab-internal,🏢 Корпоративная сеть
  - DOMAIN-SUFFIX,local,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT

Шаг 3: правила для зарубежных сервисов

  # ===== 3. явно проксируемое =====
  - DOMAIN-SUFFIX,github.com,🚀 Зарубеж
  - DOMAIN-SUFFIX,githubusercontent.com,🚀 Зарубеж
  - DOMAIN-SUFFIX,docker.io,🚀 Зарубеж
  - DOMAIN-SUFFIX,npmjs.org,🚀 Зарубеж
  - DOMAIN-SUFFIX,pypi.org,🚀 Зарубеж
  - DOMAIN-SUFFIX,openai.com,🚀 Зарубеж
  - RULE-SET,proxy-list,🚀 Зарубеж

Шаг 4: локальное и перехват остатка

  # ===== 4. локально напрямую =====
  - RULE-SET,direct-list,🇨🇳 Локально напрямую
  - RULE-SET,cn-ip,🇨🇳 Локально напрямую,no-resolve
  - GEOIP,CN,🇨🇳 Локально напрямую

  # ===== 5. перехват остатка =====
  - MATCH,🐟 Прочее

DNS тоже надо маршрутизировать

Это чаще всего упускаемая часть. Внутренние имена обязаны разрешаться корпоративным DNS, иначе они либо не резолвятся, либо резолвятся не туда.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.mycompany.com"        # внутренние имена минуют fake-ip
    - "+.corp.internal"
    - "+.pool.ntp.org"

  default-nameserver: [223.5.5.5, 119.29.29.29]
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

  # ключевая часть: отправлять конкретные имена конкретным резолверам
  nameserver-policy:
    "+.mycompany.com": "10.10.0.53"       # корпоративный DNS-сервер
    "+.corp.internal": "10.10.0.53"
    "geosite:cn": [223.5.5.5, 119.29.29.29]
    "geosite:geolocation-!cn": [https://1.1.1.1/dns-query]

  fallback:
    - https://1.1.1.1/dns-query
    - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    geoip-code: CN
Полный путь одного внутреннего имениЗапрос к gitlab.mycompany.comприложение спрашиваетСрабатывает fake-ip-filterфиктивный адрес не возвращаетсяСрабатывает nameserver-policyпередано резолверу 10.10.0.53Возвращён настоящий внутренний10.20.30.40Совпадает правилоIP-CIDR 10.0.0.0Уходит напрямуючерез туннель VPN
Нужны все три звена: обойти fake-ip, взять внутренний резолвер и дать правилу по диапазону отправить это напрямую

nameserver-policy — сердце всей схемы. Без него внутренние имена уходят на публичный резолвер, и в ответ приходит либо NXDOMAIN, либо страница-заглушка провайдера.

Частые конфликты и что с ними делать

Конфликт 1: корпоративный VPN и TUN дерутся за маршруты

Корпоративные VPN-клиенты (Cisco AnyConnect, FortiClient, продукты SSL VPN) обычно переписывают таблицу маршрутизации. Режим TUN в Clash Verge делает то же самое, и они легко сталкиваются.

Что делать, по убыванию предпочтительностиПредпочесть один системный прокси без TUN — минимальная поверхность конфликтаЕсли без TUN нельзя, пропишите внутренние диапазоны VPN явными правилами DIRECTПоменяйте порядок: сначала подключить VPN, потом включить TUNИсключите адаптер VPN в конфигурации TUN через exclude-interfaceЕсли VPN принудительно строит полный туннель — обычно сосуществование невозможно и придётся выбрать одно

Синтаксис exclude-interface:

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  exclude-interface: ["ppp0", "Cisco AnyConnect"]

Имя адаптера смотрите через ipconfig на Windows, ifconfig или ip link на Linux и macOS.

Конфликт 2: у работодателя стоит система управления рабочими станциями

Продукты EDR могут счесть виртуальный адаптер аномалией. В этом случае:

  • Не включайте TUN, пользуйтесь только системным прокси
  • Или просто занимайтесь личными делами на личном устройстве, а рабочую машину держите чистой

Конфликт 3: внутренний сервис ушёл через прокси

Симптом: внутренняя система уходит в таймаут, а на странице подключений виден зарубежный узел.

Разбор:

  1. Прочитайте столбец «Rule» на странице подключений, чтобы понять, что совпало
  2. Если совпало MATCH или GEOIP, значит, ваши корпоративные правила не сработали
  3. Проверьте написание доменных правил; проверьте, не перехватило ли их более широкое правило выше
  4. Через prepend-rules вытолкните корпоративные правила в самое начало

Конфликт 4: локальный сайт ушёл через прокси и поднял антифрод

Симптом: банк сообщает о входе из необычного места, платёжная платформа требует второй фактор.

Причина: этих сайтов нет в direct-list, а их разрешённые IP не попадают в GEOIP CN (они могут стоять на зарубежной CDN).

Решение: добавить правила руками

prepend-rules:
  - DOMAIN-SUFFIX,icbc.com.cn,🇨🇳 Локально напрямую
  - DOMAIN-SUFFIX,alipay.com,🇨🇳 Локально напрямую
  - DOMAIN-SUFFIX,unionpay.com,🇨🇳 Локально напрямую

Маршрутизация по устройствам (сценарии LAN)

Если Clash работает на софт-роутере или раздаётся другим устройствам, можно различать по исходному IP:

prepend-rules:
  # рабочий ноутбук: проксируются только зарубежные сервисы
  - AND,((SRC-IP-CIDR,192.168.1.100/32),(GEOIP,CN)),DIRECT
  # ТВ-приставка: всё через прокси
  - SRC-IP-CIDR,192.168.1.200/32,🚀 Зарубеж
  # устройства IoT: всё напрямую
  - SRC-IP-CIDR,192.168.1.0/24,DIRECT

Сопоставление по-прежнему идёт сверху вниз, так что конкретные устройства ставятся выше правила для подсети.

Как проверить, что всё работает

Четыре проверки1Корпоративная сетьоткройте внутреннюю систему в браузере; на странице подключений должно быть "Корпоративная сеть → DIRECT"2Локальнозайдите на локальный сайт; должно быть "Локально напрямую → DIRECT" с GEOIP,CN или набором правил в столбце Rule3Зарубежзайдите на github.com; должно быть "Зарубеж → какой-то узел"4DNSвыполните nslookup gitlab.mycompany.com в терминале; должен вернуться внутренний IP, а не 198.18.x.x
Все четыре сходятся — значит, разделение действительно работает

Коротко

Ключи к сосуществованию всех трёх:

  • Корпоративной сети нужны все три вещи: доменные правила, правила по диапазонам и nameserver-policy
  • Порядок правил: корпоративная сеть → явные зарубежные записи → локальные списки → GEOIP → MATCH
  • При конфликте VPN и TUN предпочитайте один системный прокси
  • Каждый класс сделайте группой политик, чтобы во время диагностики можно было переключить его в интерфейсе

Смотрите также: конфигурация DNS и справочник по типам правил.


Смежные документы

Справочник по типам правил Clash — DOMAIN, IP-CIDR, GEOIP, PROCESS-NAME и остальные
Правила и маршрутизация Справочник по типам правил Clash — DOMAIN, IP-CIDR, GEOIP, PROCESS-NAME и остальные

Синтаксис, логика сопоставления и относительная стоимость каждого типа правил, что на самом деле делает no-resolve, почему порядок правил решает всё, и как узнать, какое правило сработало.

2026-07-251168 слов3 мин чтения
Удалённые наборы правил через rule-providers — behavior, format и стратегия обновления
Правила и маршрутизация Удалённые наборы правил через rule-providers — behavior, format и стратегия обновления

Как заменить сотни написанных руками правил внешними списками. Разница между behavior domain, ipcidr и classical, text против yaml, как задавать интервал обновления и что проверять, когда набор не работает.

2026-07-211118 слов3 мин чтения
Маршрутизация отдельных программ правилами PROCESS-NAME
Правила и маршрутизация Маршрутизация отдельных программ правилами PROCESS-NAME

Полная картина маршрутизации по процессам: включение find-process-mode, поиск имени процесса, PROCESS-NAME против PROCESS-PATH, стоимость по производительности и почему написанное правило ничего не делает.

2026-06-221122 слов3 мин чтения