В крупных компаниях — особенно в банках, телекомах и государственных организациях — корпоративная сеть устроена так, что весь трафик проходит через периметр безопасности. Это означает:

  • DPI (Deep Packet Inspection),

  • SSL-инспекция,

  • корпоративные прокси,

  • фильтрация DNS,

  • сквозной мониторинг,

  • ограничение доступа к внешним ресурсам.

Для разработчиков и инженеров это часто превращает работу в пытку:

  • docker pull работает медленно или вовсе не работает;

  • WebSocket-соединения рвутся;

  • SSH-туннели нестабильны;

  • часть внешних API ломается под SSL-перехватом;

  • многие dev-инструменты работают некорректно;

  • внутренние сервисы компании доступны только через LAN, а Wi-Fi/LTE — бесполезны.

При этом нужно одновременно:

  • обращаться к GitLab/Jira/Confluence/K8s/CI/CD внутри компании;

  • и иметь нормальный интернет для разработки, библиотек, API и инструментов.

Linux по умолчанию использует только один «основной» маршрут. Но с помощью policy routing можно заставить его работать умнее.

Policy Routing — направляем разные IP через разные интерфейсы

Policy routing позволяет задать правила:

  • если трафик идёт к конкретным подсетям или IP → отправлять через LAN (внутренняя сеть)

  • если трафик идёт куда угодно ещё → отправлять через Wi-Fi (интернет)

Это решает все проблемы разработчиков:

  • внутренние сервисы доступны напрямую;

  • интернет свободен от корпоративных ограничений;

  • два мира существуют параллельно и не мешают друг другу.

Пример: разные внутренние сервисы — разные IP

Например, мы имеем такие внутренние сервисы:

Сервис

Пример домена

Пример IP (фиктивный)

Внутренний GitLab

git.company.lan

10.20.40.10

Confluence

confluence.company.lan

10.20.50.20

Портал сотрудников

portal.company.lan

10.20.60.30

Внутренний CI/CD

ci.company.lan

10.21.10.40

Внутренний Artifactory

art.company.lan

10.21.20.50

Kubernetes API

k8s.company.lan

10.30.0.1

Плюс целые подсети для микросервисов:

  • 172.16.0.0/16 — микросервисы

  • 10.10.0.0/16 — внутренняя сеть приложений

Мы хотим:

  • всё, что связано с этими IP → через LAN

  • всё остальное → через Wi-Fi

1. Создаем собственную таблицу маршрутизации

Открываем:

sudo gnome-text-editor /etc/iproute2/rt_tables

Добавляем:

100 lanroute

2. Маршруты к корпоративным сервисам (примеры)

# GitLab
sudo ip route add 10.20.40.10 dev enp0s31f6 src 192.168.50.10 table lanroute

# Confluence
sudo ip route add 10.20.50.20 dev enp0s31f6 src 192.168.50.10 table lanroute

# Портал сотрудников
sudo ip route add 10.20.60.30 dev enp0s31f6 src 192.168.50.10 table lanroute

# Внутренний CI/CD
sudo ip route add 10.21.10.40 dev enp0s31f6 src 192.168.50.10 table lanroute

# Artifactory
sudo ip route add 10.21.20.50 dev enp0s31f6 src 192.168.50.10 table lanroute

# Kubernetes API
sudo ip route add 10.30.0.1 dev enp0s31f6 src 192.168.50.10 table lanroute

# Подсети микросервисов
sudo ip route add 172.16.0.0/16 dev enp0s31f6 src 192.168.50.10 table lanroute
sudo ip route add 10.10.0.0/16 dev enp0s31f6 src 192.168.50.10 table lanroute

3. Создаем правила Policy Routing

sudo ip rule add to 10.20.40.10 lookup lanroute
sudo ip rule add to 10.20.50.20 lookup lanroute
sudo ip rule add to 10.20.60.30 lookup lanroute
sudo ip rule add to 10.21.10.40 lookup lanroute
sudo ip rule add to 10.21.20.50 lookup lanroute
sudo ip rule add to 10.30.0.1 lookup lanroute

sudo ip rule add to 172.16.0.0/16 lookup lanroute
sudo ip rule add to 10.10.0.0/16 lookup lanroute

Проверить:

ip rule list
ip route show table lanroute

4. Автоматизация (скрипт + systemd)

/etc/networkd-dispatcher/routings.sh

#!/bin/bash

ip route add 10.20.40.10 dev enp0s31f6 src 192.168.50.10 table lanroute
ip route add 10.20.50.20 dev enp0s31f6 src 192.168.50.10 table lanroute
ip route add 10.20.60.30 dev enp0s31f6 src 192.168.50.10 table lanroute
ip route add 10.21.10.40 dev enp0s31f6 src 192.168.50.10 table lanroute
ip route add 10.21.20.50 dev enp0s31f6 src 192.168.50.10 table lanroute
ip route add 10.30.0.1 dev enp0s31f6 src 192.168.50.10 table lanroute

ip route add 172.16.0.0/16 dev enp0s31f6 src 192.168.50.10 table lanroute
ip route add 10.10.0.0/16 dev enp0s31f6 src 192.168.50.10 table lanroute

for NET in \
  "10.20.40.10" \
  "10.20.50.20" \
  "10.20.60.30" \
  "10.21.10.40" \
  "10.21.20.50" \
  "10.30.0.1" \
  "172.16.0.0/16" \
  "10.10.0.0/16"
do
    while ip rule list | grep -q "to $NET lookup lanroute"; do
        ip rule del to $NET lookup lanroute
    done
    ip rule add to $NET lookup lanroute
done

systemd unit: /etc/systemd/system/routings.service

[Unit]
Description=LAN routing rules
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/etc/networkd-dispatcher/routings.sh
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

5. Добавление внутренних доменных имён в /etc/hosts

Если корпоративная сеть использует внутренние DNS-имена, то без LAN они обычно не резолвятся.
Чтобы обращаться к внутренним сервисам по привычным доменным именам, можно прописать их вручную в /etc/hosts.

Формат файла:

<IP>    <hostname>

Примеры внутренних сервисов (IP — фиктивные):

sudo gnome-text-editor /etc/hosts

Добавляем строки:

# Внутренний GitLab
10.20.40.10     git.company.lan

# Confluence
10.20.50.20     confluence.company.lan

# Портал сотрудников
10.20.60.30     portal.company.lan

# CI/CD
10.21.10.40     ci.company.lan

# Artifactory
10.21.20.50     art.company.lan

# Kubernetes API
10.30.0.1       k8s.company.lan

После сохранения можно проверить:

ping git.company.lan
curl -I https://confluence.company.lan
kubectl cluster-info --server=https://k8s.company.lan:6443

Теперь:

  • домены будут работать даже если корпоративный DNS недоступен,

  • LAN-трафик для этих адресов будет автоматически идти через таблицу lanroute,

  • запросы к другим доменам не попадут в корпоративную сеть.

Это особенно полезно в сочетании с policy routing:
мы прописываем домены → они резолвятся в нужные IP → policy routing отправляет их в LAN → всё работает стабильно.

6. Работа с внутренними SSL-сертификатами: корневые CA, недоверенные цепочки и советы разработчикам

Во внутренних корпоративных сетях HTTPS-сервисы часто используют:

  • самоподписанные сертификаты,

  • сертификаты, выпущенные внутренним CA,

  • промежуточные цепочки, которые не доверены внешним браузерам,

  • или SSL-инспекцию, подменяющую сертификаты “на лету”.

Снаружи такие сертификаты невалидны, и стандартные инструменты (curl, docker, git, kubectl) выдают ошибки:

x509: certificate signed by unknown authority
SSL: no alternative certificate subject name matches
unable to verify the first certificate

Чтобы внутренняя инфраструктура работала корректно, нужно добавить корневой сертификат корпоративного CA в систему.

Ниже — универсальная схема, подходящая для Ubuntu / Debian / Linux Mint и всех производных.

6.1. Получение корневого сертификата компании

Обычно его можно взять:

  • на внутреннем портале ИБ,

  • в инструкции по подключению VPN,

  • в корпоративном GitLab / Confluence,

  • через сотрудника ИБ,

  • или скачать прямо с сервера:

echo -n | openssl s_client -connect git.company.lan:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > company-root-ca.crt

Если используется промежуточная цепочка — нужно выгрузить всю цепочку, не только leaf-сертификат.

6.2. Куда помещать сертификат в Linux

На Debian-подобных системах (Ubuntu):

Скопировать файл в директорию доверенных сертификатов:

sudo cp company-root-ca.crt /usr/local/share/ca-certificates/company-root-ca.crt

Обновить системное хранилище:

sudo update-ca-certificates

После этого сертификат станет доверенным для:

  • curl

  • git

  • docker

  • kubectl

  • apt

  • go get

  • python/pip

  • java (иногда нужно дополнительно, см. ниже)

6.3. Проверка доверия

openssl verify company-root-ca.crt

Проверить сайт:

curl -v https://git.company.lan

Git:

GIT_CURL_VERBOSE=1 git ls-remote https://git.company.lan

6.4. Java / JVM: отдельный truststore

Java не использует системное хранилище.
Для внутренних сервисов (Jenkins, Maven, Java-приложения) требуется импорт:

sudo keytool -importcert \
  -alias company-root-ca \
  -file company-root-ca.crt \
  -keystore /etc/ssl/certs/java/cacerts \
  -storepass changeit

Проверка:

keytool -list -keystore /etc/ssl/certs/java/cacerts | grep company

6.5. Docker: особые правила

Docker доверяет сертификатам из папки:

/etc/docker/certs.d/<registry-hostname>/

Например, для внутреннего registry:

sudo mkdir -p /etc/docker/certs.d/registry.company.lan
sudo cp company-root-ca.crt /etc/docker/certs.d/registry.company.lan/ca.crt
sudo systemctl restart docker

Проверка:

docker pull registry.company.lan/backend/app:latest

6.6. Браузеры и приложения

Chrome / Chromium

Используют системный trust store — ничего дополнительно делать не нужно.

Firefox

Имеет внутренний trust store.
Импорт вручную:

Settings → Privacy & Security → Security → View Certificates → Authorities → Import

Что это даёт

1. GitLab, Confluence, портал, CI/CD, Artifactory, K8s — доступны напрямую

Через LAN, быстро, стабильно, без VPN.

2. Всё остальное — через Wi-Fi

Быстрый интернет, без корпоративного перехвата.

3. Полное разделение трафика

LAN получает только то, что явно указано.

4. Dev-инструме��ты работают идеально

Docker, PyPI, Go proxy, Maven, NPM и всё остальное.

5. Предсказуемость + удобство

Два мира — в одной машине, без переключений.