Два шлюза на одном роутере

Для чего нужно разграничение трафика

В офисах нередко возникает задача реализовать доступ в интернет таким образом, чтобы сёрфинг и скачивание файлов не мешали работе сервисов, требовательных к качеству линии: например, IP-телефонии и видео наблюдению. Если IP-телефония будет работать на той же линии, через которую офисные пользователи открывают сайты и скачивают файлы, качество связи заметно снизится: аудио потом будет прерываться, а голоса собеседников могут искажаться (как говорят в народе «квакать») В таком случае линия будет перегружена, или, как говорят сисадмины, «канал завален».

Как разграничить трафик

Для решения проблемы можно настроить приоритет определённого вида трафика. Для этого в качестве шлюза необходимо иметь либо дорогое устройство от CISCO, либо полноценный сервер. Но проще и надёжнее использовать разные независимые каналы в Интернет. Это могут быть либо две независимые линии одного и того же провайдера, или же линии двух различных провайдеров. Конечно же, лучше иметь две линии от разных провайдеров — в случае проблем у одного провайдера выручит другой.

Так как же построить такую схему локальной сети, при которой разные устройства в локальной сети будут выходить в Интернет через разных провайдеров или просто через разные шлюзы? А схема эта довольно проста.

Настройка подключения к Интернету разных устройств через разные шлюзы

Коммутационная схема

1. Два роутера подключаются к двум разным провайдерам через WAN-порты.

2. Между собой роутеры соединяются Ethernet-кабелем (витой парой) через LAN-порты.

3. К роутерам подключены компьютеры, сетевые МФУ через LAN-порты и ноутбуки по Wi-Fi.

Настройка роутеров

Роутер №1.

Подключён к Провайдеру А.
IP-адрес 192.168.1.1
Маска подсети 255.255.255.0
DHCP-сервер включён.

Роутер №2.

Подключён к Провайдеру Б.
IP-адрес 192.168.1.254
Маска подсети 255.255.255.0
DHCP-сервер выключен.

Настройка компьютеров

1. Все компьютеры и другие устройства, которые должны подключаться к Интернету через провайдера А (соответственно, через шлюз №1), должны быть настроены на автоматическое получение сетевых параметров в свойствах сетевых адаптеров:

2. На компьютерах, которые должны использовать провайдера Б (шлюз №2), нужно вручную задать IP-адреса, а в качестве шлюза и DNS-сервера указать IP-адрес роутера №2, т.е. в нашем примере 192.168.1.254:

Назначая IP-адреса вручную, важно не указать уже используемый адрес. Мы советуем на роутере №1 задать пул DHCP с запасом, а вручную указывать адреса из другого диапазона. Например, на роутере с включённым DHCP-сервером указываем диапазон DHCP 192.168.1.20-100, а на устройствах, которые должны выходить в Интернет через шлюз №2, будем указывать вручную адреса из диапазона 192.168.1.150-200.

Выводы

Эта схема хороша тем, что в любой момент на любом устройстве, подключённом к любому из роутеров, вы можете выйти в Интернет через любой шлюз. Если нужен шлюз №1, установите в свойствах сетевой карты автоматическое получение всех сетевых параметров. Если нужно выйти через шлюз №2, настройте сетевые параметры вручную, как мы показали. При такой коммутационной схеме неважно, в LAN-порт какого роутера подключено устройство, т.к. они находятся в одном сегменте сети. Кстати, Wi-Fi — это тоже LAN, только без проводов.

При желании, можно сделать так, что одним устройствам будет автоматически выдаваться шлюз провайдера А, а другим — шлюз провайдера Б. Но для этого нужно конфигурировать DHCP-сервер. В бюджетных роутерах прошивка не позволяет вносить такие коррективы во встроенный DHCP-сервер. Поэтому, придётся либо установить прошивку DD-WRT, либо поднять службу DHCP на реальном сервере. Но в этой статье мы рассматривали простое решение и усложнять его не будем.

I think you misunderstood how a router process a packet, thus coming with a solution that is not at all appropriate for your needs.

Why?

Let say computer A has the following configuration:

• mac address 00:53:BA:12:17:19
• IP address 192.168.0.7
• subnet mask of 255.255.255.0
• default gateway 192.168.0.1

A send a packet to the internet host www.example.com which has IP address 203.0.113.5.
The packet has the following characteristics:

• source IP address : 192.168.0.7
• destination IP address: 203.0.113.5

It compare (in binary) its subnet mask with the destination IP address and find that the destination is not on the local subnet, so it will send the packet to its default gateway, 192.168.0.1

It lookup in its ARP table and if needed perform an ARP request to find the mac address of the host which hold the 192.168.0.1 IP address.
It finds 00:53:00:17:a7:b3

Then it builds a frame with the following characteristics:

• source mac address: 00:53:BA:12:17:19
• destination mac address: 00:53:00:17:a7:b3

inside this ethernet frame the IP packet is encapsulted, and it still has:

• source IP address : 192.168.0.7
• destination IP address: 203.0.113.5

As you can seed the destination IP address is NOT the gateway.

So the router receive this frame, strip the Ethernet header and lookup the packet to perform a routing decision.

The basic of routing is that the routing decision is made solely on the destination IP address, 203.0.113.5
The router then look in its routing table, find a route for 203.0.113.5 and send the packet through the associated interface (performing NAT if configured which is required here).

As you can see, the IP address of the gateway that was used has no role in the routing decision. And, more importantly, the router does not even know what was this IP address. It only know on which interface the frame arrived

Ok so, why not configuring 2 different gateways on two different interfaces. Well you can’t, not on a Cisco router. You cannot have two overlapping networks on two different layer 3 interfaces. Otherwise the router could not decide on which interface it must send a packet for this network.

This is why your dual gateway cannot work.
But more importantly, it’s not required to achieve your goal.

What could work?

Now if you want the router to take a different routing decision based on the sender, it is possible. It’s called policy based routing (PBR)

PBR allow you to configure different routing table on the router, and perform routing decision on different criteria.

The most common (and easy to configure) criteria are the source IP address and destination IP address.

Note that you can specify the outgoing interface rather than the next-hop IP, which is handy for a outgoing interface configured by DHCP.

So what you have to do (if I understood correctly what you want), is to:

• set a group of computers with specific IP address pool (fixed IP, DHCP reservations)
• set another group of computer with a second IP address pool
• write a route map that will set the destination IP or outgoing interface for each pool
• activate PBR on the incoming interface (the one that has the LAN gateway)

To manually change the outgoing interface for some computer in case one link fail, you just have to alter the route-map, which is a matter of minutes.

You can have 4 pools for example:

• computers that will always use ISP 1, and never fail-over to ISP2
• computers that will always use ISP 2, and never fail-over to ISP1
• computer that will use ISP 1 if available, and manually fail-over to ISP2 if needed
• computer that will use ISP 2 if available, and manually fail-over to ISP1 if needed

Здравствуйте!

Встала задача, которую сам никак не решу.

Имеется два подразделения (отдела) в одной организации.
В каждом настроена своя сеть и интернет через ADSL-роутеры с включёнными на них WiFi и DHCP.
У части специалистов настольные компьютеры, у некоторых – ноутбуки.
Временами (для выполнения некоторых работ) приходят люди со своими ноутбуками, которым нужна сеть (интернет и ресурсы). Постоянно в этом отделе они не сидят. Они могут прийти в любой отдел и сесть там поработать в интернете и/или с общими ресурсами в сети.
С мобильников тоже сидят в интернете.

Ничего вроде бы сложного: установили роутеры, настроили всё по умолчанию и работают.

Но теперь потребовалось соединить эти две сети так, чтобы:
1) со всех компьютеров (в т.ч. и «приходящих» ноутбуков) можно было пользоваться ресурсами обоих отделов.
2) иметь интернет на моб. телефонах.
3) иметь раздельный интернет в отделах, т.к. каждое подразделение платит за свой и не хочет никого постороннего в него впускать. Да и если оба отдела сядут на один шлюз, то скорости ADSL не хватит.
4) на мобильных вещах параметры сети были автоматом (от DHCP). А на стационарных компьютерах адреса, шлюзы и прочие прелести пишутся статические.

Если бы не мобильники и личные ноутбуки, в которых прописать шлюзы и др. не представляется удобным, то всё бы хорошо работало. Везде задали бы IP, шлюз каждому от его отдела, отключили бы все DHCP и ура.
Но мобильные вещи всё портят. Если кто-то пришёл поработать с ноутом, то ему надо писать адреса и шлюзы того отдела, куда он пришёл. Неудобно. В мобильнике ещё неудобнее. Особенно для тех, кто «ходит» по разным отделам. Поэтому и требуется для них DHCP.
Настольные компьютеры – статические адреса.

До сего времени в Сети 2 стоит неуправляемый коммутатор. Он там стоит потому, что портов в роутере «Р-2» всего четыре, а компов больше.

Но есть возможность кинуть кабель между отделами. На рисунке он зелёного цвета. И видимо нужно будет заменить свитч «???» на нечто более умное.

Думается, что это нечто более умное должно блокировать DHCP-запросы между сетями.
Изолировать вай-фай от локалки роутеры в настройках позволяют, но нельзя, потому что ноутам нужен не только интернет, но и ресурсы в сети (в отличие от мобильников).
Оставить один DHCP не получается, т.к. адреса будут хвататься для всех с него одного, соответственно и шлюз один. И поэтому будут все сидеть в «одном» интернете, а не раздельно по отделам.

Подскажите, пожалуйста, как сие организовать? Ибо моих знаний уже не хватает.

PS. Отдельный сервер ставить возможности нет. Выделить компьютер по сервер тоже никак – все компы заняты специалистами. Общие ресурсы – это «расшаренные» папки и принтеры. У одного, например, папка с отчётами, у другого – база 1С. И т.д. Это их дело, предлагать им кардинально менять енто дело не хочется. Там контингент возрастной и сказать им «вы делали так, а теперь будете вот так и после ещё так» – проще уволиться.

Материал из Xgu.ru

Перейти к: навигация, поиск

ОС и ПО: Linux, OpenVPN

Автор: Игорь Чубин

Короткий URL: openvpn/gw

На странице описывается как с помощью OpenVPN и двух независимых
интернет-каналов низкой надёжности
организовать надёжное подключение
удалённой сети (или системы) к центральной сети.

Приведённое решение может быть полезно и без использования
VPN — для решения задачи автоматического выбора основного шлюза.

[править] Задача

Есть два канала связи с Интернетом, через двух независимых провайдеров.
Один из каналов является основным, второй — резервным.
Резервный канал нужно использовать только тогда, когда недоступен
основной.

Нужно сделать так, что бы как только Интернет становится недоступным
через одно из соединений (не имеет значения из-за того что пропала связь с провайдером,
или потому что проблемы у провайдера),
автоматически менять маршрут по умолчанию
и использовать другой канал.

Как только связь через основной канал восстанавливается,
необходимо возвращаться на его использование.

Рассмотреть ситуацию, когда компьютер входит в другую сеть
через OpenVPN:

• OpenVPN должен перестартовывать после смены маршрута;
• (Важно!) когда OpenVPN-соединение установлено, маршрут по умолчанию направлен в частную сеть через OpenVPN.

Если OpenVPN не используется,
ничего страшного — задача только упрощается.

[править] Схема

Схема включения шлюза gw
в Интернет и локальную сеть (LAN),
показана ниже.

            +-------+
            |CENTRAL|
            |  VPN  |
            |  HUB  |
            +---+---+
                |
           _____._
      ____/       \___
   __/                \
  /                    \__
 |                        \
  \       Internet         |
   |                       |
    \ _                   .
       \              ___/
        \___         _/
            \_______/
            GW1   GW2
             *     *
             ||    |
         IP1 ||    | IP2
      [eth1] ||    | [eth2]
            +-------+
            |       |
            |  gw   |
            |       |
            +---+---+
                | [eth0]
                |-
               LAN

• CENTRAL VPN HUB — центральный VPN-концентратор, на который нужно держать VPN-канал;
• GW1 — шлюз первого провайдера, на интерфейсе с нашей стороны установлен IP-адрес IP1 (предпочитаемый канал, отмечен двойной линией);
• GW2 — шлюз второго провайдера, на интерфейсе с нашей стороны установлен IP-адрес IP2.

На шлюзе gw работает VPN-клиент, который через Интернет
должен устанавливать туннель
на центральный VPN-сервер (CENTRAL VPN HUB).

[править] Файл /etc/network/gateways

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

• IP1 — адрес первого интерфейса (eth1);
• IP2 — адрес второго интерфейса (eth2);
• GW1 — адрес шлюза, доступного через первый интерфейс;
• GW2 — адрес шлюза, доступного через второй интерфейс;
• DEFAULTGW — адрес предпочитаемого (один из GW1 и GW2) шлюза (если он работает, лучше использовать его).

Пример файла /etc/network/gateways

#### ISP 1
IP1=10.0.1.1
GW1=10.0.1.2

#### ISP2
IP2=10.0.4.1
GW2=10.0.4.4

### Let ISP1 be default
DEFAULTGW=${GW1}

Для того чтобы избежать случайного внутреннего противоречия
в настройках, стоит использовать эти адреса и при настройке интерфейсов.
Например, для Debian GNU/Linux, если настройка интерфейса выполняется статически
через файл /etc/network/interfaces:

iface eth1 inet manual
    up sh -c '. /etc/network/gateways ; ifconfig eth1 $IP1'
iface eth2 inet manual
    up sh -c '. /etc/network/gateways ; ifconfig eth2 $IP2'

(если при настройке интерфейса нужно указывать и маску,
следует добавить соответствующую переменную в файл /etc/network/gateways
и использовать её при настройке интерфейса).

[править] Автоматическая правка файла /etc/network/gateways

IP-адреса сетевых интерфейсов и шлюзов,
указанные в файле /etc/network/gateways,
могут изменяться, при условии, что они назначаются
динамически при конфигурировании интерфейса.
В этом случае необходимо чтобы файл отражал
изменения адресов.

Автоматическая правка файла /etc/network/gateways
возможно с помощью скрипта,
который вызывается при поднятии соответствующего
интерфейса.

Для Debian GNU/Linux это можно сделать
или указав скрипт в директиве up
в файле /etc/network/interfaces
или разместив в соответствующем каталоге,
например /etc/ppp/ip-up.d/.

Пример скрипта который вызывается при поднятии интерфейса
показан ниже.
Здесь интерфейс соответствует каналу 1,
и поэтому он правит переменные GW1
и IP1.

Пример. Скрипт автоматической правки файла /etc/network/gateways, вызываемый при подъёме интерфейса.

#!/bin/sh
case $1 in
  ppp200)
    /bin/ip rule add from $4 lookup 3
    /bin/ip route add default via $5 table 3
    /usr/bin/perl -i -p -e 's/GW1=.*/GW1='"$5"/  /etc/network/gateways
    /usr/bin/perl -i -p -e 's/IP1=.*/IP1='"$4"/  /etc/network/gateways
;;
esac
exit 0

[править] Маршрутизация с двумя шлюзами

Маршрутизатор имеет два интерфейса, которые смотрят в Интернет
через двух провайдеров (два другие независимые шлюза).
При простой настройке маршрут по умолчанию может быть только один.
Это означает, что весь трафик со шлюза (за исключением трафика, адресованного
в непосредственно подключенные сети, и сети, маршрут в которые явно указан)
будет уходить через это маршрут.

Нам необходимо сделать так, чтобы шлюз отправлял
пакеты в интернет, в зависимости от того,
какой у них обратный адрес:

• трафик с интерфейса eth1 должен уходить через GW1;
• трафик с интерфейса eth2 должен уходить через GW2.

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

Эту задачу можно решить с помощью policy routing, настройка которой
в Linux возможна с помощью iproute2.

Например для шлюзов GW1 и GW2, которые описываются в /etc/network/gateways:

. /etc/network/gateways
ip rule add from $IP1 lookup 2
ip rule add from $IP2 lookup 3
ip route add default via $GW1 table 2
ip route add default via $GW2 table 3
ip route add default via $DEFAULTGW

Такая схема маршрутизации не будет правильно работать с iptables DNAT. Другими словами, если с помощью iptables/netfilter пробрасывать обращения на какие-то порты внутрь сети, принцип «ответы уходят по тому каналу, по которому приходят запросы» работать не будет. Один из способов решения проблемы описан ниже, в разделе «Два шлюза в Интернет и NAT».

[править] Автоматическая смена маршрута по умолчанию

Основной маршрут нужно изменить, когда он перестаёт работать.
Как проверить, что маршрут больше не работает?

Самое простое — проверять доступность ближайшего по этому маршруту
шлюза, то есть шлюза провайдера.
Это способ плох тем, что шлюз провайдера может быть доступен,
но у самого провайдера могут быть проблемы со связью.

Лучший способ — проверять доступность сервера, на который
должен быть установлен туннель через тот или иной канал.
Это можно сделать путём отправки ICMP-запросов с того или иного
интерфейса.

Скрипт использует второй способ.
Каждые 30 секунд (CHECK_INTERVAL) выполняется проверка.
Как только связь через приоритетный шлюз теряется,
а связь через второй шлюз при этом есть,
производится переход на использование
второго шлюза в качестве основного.

При восстановлении связи через приоритетный шлюз,
скрипт переводит систему на использование его в качестве основного (default gateway).

При любой смене шлюза (как с приоритетного на резервный, так и наоборот)
в syslog попадает сообщение о том, что шлюз поменялся,
и указывается причина этого изменения:

Sep  3 13:12:15 stab /usr/local/bin/change_default_route: Gateway 199.5.5.111 (199.5.5.112) is not usable. Trying 221.42.167.30 (221.
42.167.29)
Sep  3 13:12:16 stab /usr/local/bin/change_default_route: Changing default route from 199.5.5.111 to 212.42.167.30

[править] Скрипт change_default_route

Состояние шлюзов контролирует скрипт,
change_default_route,
работающий в соответствии с вышеописанным алгоритмом.

Переменные, которые должны быть заданы в скрипте:

• GW_CONF — имя файла /etc/network/gateways (или другое, если он называется иначе)
• OPENVPN_UPLINK — имя конфигурации OpenVPN;
• CHECK_INTERVAL — периодичность проверки доступности удалённой точки через шлюзы, в секундах.

Имя конфигурации OPENVPN_UPLINK определяет имя конфигурационного файла OpenVPN и процесс openvpn, который должен быть перезапущен после смены маршрута.
Например,

   OPENVPN_UPLINK=kiev

соответствует конфигурационный файл

   /etc/openvpn/kiev.conf

IP-адрес VPN-сервера, с которым должен устанавливаться туннель,
и на возможность связи с которым постоянно проверяются шлюзы,
определяется из этого конфигурационного файла,
из директивы remote.

Скрипт может быть размещён, например, здесь:

   /usr/local/sbin/change_default_route

Скрипт должен вызываться автоматически при старте системы.
Например, в /etc/rc.local:

nohup /usr/local/sbin/change_default_route &

или в /etc/network/interfaces

iface ...
 ....  
 up nohup /usr/local/sbin/change_default_route &

Скрипт /usr/local/sbin/change_default_route

#!/bin/sh

############################################################
# 
# Set the variables berfore starting the script:

GW_CONF=/etc/network/gateways
OPENVPN_UPLINK=kiev
CHECK_INTERVAL=30               #seconds between gw check

#############################################################

OPENVPN_UPLINK_CONFIG=/etc/openvpn/${OPENVPN_UPLINK}.conf

log()
{
  echo "$@" | logger -t $0 -p daemon.info
}

current_uplink_gateway()
{
    uplink_addresses=`grep ^remote ${OPENVPN_UPLINK_CONFIG} | sed s/remote// | tr -d ' \t' | tr '\n' '|';echo default `
    ip route show | grep -v tun | egrep "^($uplink_addresses)" | awk '{print $3}' | tail -1
}

read_gateways()
{
    [ -f ${GW_CONF} ] && source ${GW_CONF}
    [ -f ${GW_CONF} ] || echo file ${GW_CONF} missing | logger -t $0 -p daemon.error
    [ -z "$GW" ] && GW=`current_uplink_gateway`
}

delete_uplink_gateway()
{
    [ -z "$GW" ] && return 
    for remote in $(grep ^remote ${OPENVPN_UPLINK_CONFIG} | sed s/remote// | tr -d ' \t')
    do
        ip route delete $remote via "${GW}"
    done
}

change_uplink_gateway()
{
    [ -z "$GW" ] && return 
    NEWGW=$1
    uplink_addresses=`grep ^remote ${OPENVPN_UPLINK_CONFIG} | sed s/remote// | tr -d ' \t' | tr '\n' '|';echo default `
    for remote in `ip route show | grep -v tun | egrep "^($uplink_addresses)" | awk '{print $3}'`
    do
        ip route change $remote via "${GW}"
    done
}
openvpn_uplink_pid()
{
#    uplink_addresses=`grep ^remote ${OPENVPN_UPLINK_CONFIG} | sed s/remote// | tr -d ' \t' | tr '\n' '|';echo FINAL_ITEM `
#    netstat -np 2> /dev/null  | grep openvpn | egrep $uplink_addresses | perl -n -e 's@/.*$@@; m@([0-9]+)$@; print $1."\n";'
    cat /var/run/openvpn.${OPENVPN_UPLINK}
}

ping_remote_site()
{
    for remote in $(grep ^remote ${OPENVPN_UPLINK_CONFIG} | sed s/remote// | tr -d ' \t')
    do
        ping -q -c 1 "$@" $remote >& /dev/null && return 0
    done
    return 1
}

set_default_route()
{
    NEWGW=$1
    [ "$GW" == "$NEWGW" ] && return 0
    log "Changing default route from $GW to $NEWGW"

#    openvpn_uplink_pid=`openvpn_uplink_pid`

    /etc/init.d/openvpn stop $OPENVPN_UPLINK

    route delete default gw "$GW"
    delete_uplink_gateway
    route add default gw "$NEWGW"

    /etc/init.d/openvpn start $OPENVPN_UPLINK

# Restarting openvpn to make him use new gw
#    [ -z "$openvpn_uplink_pid" ] && /etc/init.d/openvpn restart || kill -1 $openvpn_uplink_pid

    GW=${NEWGW}
}

while true
do
    read_gateways

    if [ "${DEFAULTGW}" = "${GW1}" ]
    then 
        if ping_remote_site -I ${IP1} 
        then 
            set_default_route ${GW1}
        else
            log "Gateway $GW1 ($IP1) is not usable. Trying $GW2 ($IP2)" 
            if ping_remote_site -I ${IP2} 
            then
                set_default_route ${GW2}
            else
                log "Uplink can't be reach by any path. Waiting" 
            fi
        fi
    else
        if ping_remote_site -I ${IP2} 
        then 
            set_default_route ${GW2}
        else
            log "Gateway $GW2 ($IP2) is not usable. Trying $GW1 ($IP1)" 
            if ping_remote_site -I ${IP1} 
            then
                set_default_route ${GW1}
            else
                log "Uplink can't be reach by any path. Waiting" 
            fi
        fi
    fi

    sleep ${CHECK_INTERVAL}
done

exit 0

[править] Дополнительные вопросы

[править] Два шлюза в Интернет и NAT

Вышеописанный способ маршрутизации
в зависимости от источника (policy routing)
не будет работать для систем внутри сети, доступных через NAT.

Другими словами, если с помощью iptables/netfilter пробрасывать
обращения на какие-то порты внутрь сети, принцип «ответы уходят по тому каналу, по которому приходят запросы»
работать не будет.

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

Один из способов решения проблемы описан
ниже.

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

            GW1   GW2
             *     *
             |     | 
         IP1 |     | IP2
      [eth1] |     | [eth2]
            +-------+
            |       |
            |  gw   |
            |       |
            +-------+
    10.0.3.250  |  10.0.3.254
        [eth0]  |  [eth0:1]
                | 
                |
    10.0.3.249  |  10.0.3.253
        [eth1]  |  [eth1:1]
            +-------+
            |       |
            |  pgw  |
            |       |
            +-------+
               | 10.0.3.6
               | [eth0]
               |

В этом случае:

• на шлюзе gw выполняется проброска на один из внутренних адресов, в зависимости от того, куда пришёл запрос;
• на шлюзе pgw выполняется дальнейшая проброска внутрь сети.

[править] Дополнительная информация

• Default gateway
• Linux Advanced Routing & Traffic Control HOWTO — перевод руководства по iproute2 и управлению трафиком в Линукс

[править] Материалы по OpenVPN на xgu.ru

• OpenVPN
• Два шлюза в Интернет и OpenVPN
• OpenVPN в Windows
• OpenVPN Bridge ­— передача тегированного трафика через VPN
• OpenVPN Proxy ARP