Zyxel Firewall [VPN Routing] - Маршрутизиране на трафика от VPN тунел към друг VPN сайт [VPN Routing]

Имате още въпроси? Подаване на заявка

Важно известие:
Уважаеми клиенти, моля, имайте предвид, че използваме машинен превод, за да предоставяме статии на вашия местен език. Възможно е не всички текстове да бъдат преведени точно. Ако има въпроси или несъответствия относно точността на информацията в преведената версия, моля, прегледайте оригиналната статия тук: Оригинална версия

В тази статия се обяснява как да се маршрутизира трафик от тунел между сайтове в друг тунел, за да се достигне до устройства зад връзка между сайтове. В нея се обяснява как да маршрутизирате трафика от сайт А към сайт Б през защитната стена/шлюза на централата (маршрутизиране от сайт към сайт през тунел от сайт към сайт), отстраняване на проблеми/проблеми, правила за маршрутизиране, ако искате клиентските ви VPN мрежи да достигат до сървър, който се намира на друг сайт (от клиент към сайт през тунел от сайт към сайт), конфигурация на SecuExtender IPSec.

Алтернатива 1: Маршрутизиране на трафика от отдалечен VPN тунел към друг VPN тунел от сайт към сайт

1) Създаване на VPN тунели

Предварително условие: Вече трябва да е установена връзка между локациите.

След като тунелът е установен, ще го свържем с помощта на L2TP през IPSec.

За инструкции как да настроите VPN, моля, вижте:

VPN - Конфигуриране на IPSec Site-To-Site VPN

Можете да намерите информация за L2TP през IPSec:

VPN - Configure L2TP over IPSec VPN using PSK [Stand-alone mode]

За да опростите процеса, можете да използвате съветника за създаване на VPN тунел и L2TP over IPSec.

2) Конфигуриране на политики за маршрутизиране

За да разрешите трафика между главния щаб (HQ) и обект В, трябва да настроите политики и маршрути за VPN тунела.

На защитната стена на централата:

  1. Създайте маршрут на политиката, който насочва входящите заявки от L2TP тунела към тунела на Сайт Б. Това е маршрутизиране на входящите заявки от тунела L2TP през защитната стена на HQ в тунела на обект B

    • Източник: Подмрежа на L2TP клиента
    • Дестинация: Подмрежата на сайта B
    • Следваща стъпка: VPN тунел "Тунел на обект Б"

Обърнете внимание, че адресът на местоназначението е адресът на нашия клиент.

2. Създайте политика, която разрешава отговорите от Сайт Б и ги насочва в тунела към Сайт Б. Това е от решаващо значение за трафика, който се връща от Сайт Б към централата.

    • Източник: Всеки
    • Дестинация: L2TP тунел
    • Следващ скок: VPN тунел "L2TP Tunnel"

На обект B:

  1. Също така създайте маршрут на политиката, който позволява входящите заявки от централата и ги препраща в тунела към сайт B. Създайте маршрут на политиката, който позволява отговорите от централата и ги препраща в тунела към сайт B:

Уверете се, че е активирано асиметричното маршрутизиране за безпроблемна свързаност. Можете да намерите тази опция тук:

Конфигурация > Политика за сигурност > Контрол на политиката

mceclip0.png

Активирането на тази функция активира "триъгълния" маршрут, което позволява на защитната стена да използва асиметрична топология на маршрута в мрежата и предотвратява нулирането на връзката при връщане на отговорите.

Като следвате тези стъпки, можете ефективно да маршрутизирате трафика между VPN тунелите и да поддържате безпроблемна и сигурна връзка между централата и обект В.

Алтернатива 2: Маршрутизиране от VPN тунел към друг VPN сайт

1) Маршрутизиране на трафика от сайт А към сайт Б през сайта на централата

mceclip9.png

Ако искате сайт А да достига до сайт Б и обратно, трябва да създадете маршрути на политиката на всяка защитна стена, за да уведомите защитната стена на централата къде да изпраща входящите заявки и къде да изпраща отговорите.

1.1 Маршрути на политиката - защитна стена на централата

На защитната стена на HQ първо трябва да конфигурирате правило, което да разрешава заявки, идващи от Сайт А, които отиват към Сайт Б. Те трябва да бъдат насочвани в тунела към Сайт Б, а това е важно както за ICMP заявките (идващи от Сайт А), така и за ICMP отговорите (идващи от Сайт Б и сега отново се връщат към Сайт Б).

Входящи: всякакви - Източник: "Подмрежа на сайт А" -> Дестинация: "Следващ тунел - "VPN тунел на сайт Б"

mceclip1.png

На второ място, трябва да конфигурирате правило, което да разрешава отговорите, идващи от Сайт Б, които отиват към Сайт А (когато сте изпратили заявка от Сайт А), и те трябва да бъдат насочени към тунела на Сайт А. Това е важно както за ICMP заявките (идващи от Сайт Б), така и за ICMP отговорите (идващи от Сайт Б и сега отново се връщат към Сайт А).

Входящи: всякакви - Източник: "Подмрежа на сайт Б" -> Дестинация: "Подмрежа на сайта А" - Следващ тунел - "VPN тунел на сайта А"

mceclip5.png

1.2 Маршрути на политиката - защитна стена на сайт А

След това трябва да конфигурирате правило, което разрешава заявки, идващи от Сайт B, които отиват към Сайт A (когато сте изпратили заявка от Сайт B). Те трябва да бъдат маршрутизирани"обратно" в тунела на Сайт А, а това е важно както за ICMP заявките (идващи от Сайт Б), така и за ICMP отговорите (идващи от Сайт Б и сега отново се връщат към Сайт Б).

Входящи: всякакви - Източник: "Подмрежа на сайт Б" -> Дестинация: "Подмрежа на сайт А" - Следваща точка "VPN тунел на сайт А"

mceclip6.png

1.3 Маршрути на политиката - защитна стена на сайт B

След това трябва да конфигурирате правило, което разрешава заявки, идващи от Сайт А, които отиват към Сайт Б (когато сте изпратили заявка от Сайт А). Те трябва да бъдат маршрутизирани"обратно" в тунела на Сайт Б, а това е важно както за ICMP заявките (идващи от Сайт А), така и за ICMP отговорите (идващи от Сайт А и сега отново се връщат към Сайт А).

Входящи: всякакви - Източник: "Подмрежа на сайт А" -> Дестинация: "Подмрежа на сайт Б" - Следваща точка "VPN тунел на сайт Б"

mceclip4.png

2) Проверка/отстраняване на неизправности

Когато сте конфигурирали всички маршрути на политиката, е важно да проверите дали маршрутизирането действително работи. Може би имате противоречащи си маршрути в правилата на защитната стена (припокриване на подмрежи, съществуващи политики/статични маршрути и т.н.) или има нещо друго нередно.

Имайте предвид, че това може да бъде много объркващо, тъй като има много маршрути, за които трябва да се погрижите. Най-лесният начин да направите това е ръчно да начертаете всички потоци от пакети на хартия (компютър -> шлюз А - шлюзът трябва да се насочи към централата, централата трябва да се насочи към сайт Б - сайт Б трябва да насочи отговора отново към централата ... и т.н.), запитайте се - "кой отговаря за маршрутизацията и налице ли е маршрутизация?".

mceclip10.png

По-долу ще намерите два сценария, при които може да се наложи да промените конфигурациите, за да работи маршрутизацията.

2.1 Тест чрез пингване на защитната стена

Първият е тестване чрез пинг от компютър на обект А към сървър или компютър на обект Б:

Червена стрелка - ICMP [ping] заявка

Зелена стрелка - ICMP [ping] отговор

2.2mМаршрути на политиката - защитна стена на сайт А

Ако изпращате пинг към шлюза на обект Б от шлюза на обект А (вграден инструмент ICMP), маршрутизацията на политиката на обект А няма да се прилага за отговорите обратно от обект Б, ако обект Б се опитва да изпрати пинг към шлюза на обект А.

Затова се нуждаем от маршрут на политиката, който изглежда така:

Входящи: ZyWall- Източник: "Подмрежата на сайт В" -> Дестинация: "Подмрежата на сайт А" - Следваща стъпка "VPN тунел на сайт А"

mceclip8.png

2.3 Маршрути на политиката - защитна стена на сайт B

Първият тест, който можете да направите, е да изпратите пинг до защитната стена, но тъй като маршрутизацията, която сега сте създали, е САМО за входящи заявки (с изключение на Zywall), това означава, че маршрутизацията няма да се прилага, ако пингът идва от Сайт А, достига до защитната стена на Сайт Б и след това защитната стена е отговорна за отговора на тази заявка. ICMP отговорът тогава ще изглежда така:

ICMP заявка

Компютър (ICMP заявка) -> шлюз на сайт А -> VPN тунел до централата -> шлюзът на централата изпраща трафик до шлюз на сайт Б

ICMP отговор

Шлюз на сайт Б (ICMP отговор) -> Шлюз на сайт Б -> VPN тунел към HQ -> Шлюз на HQ изпраща трафик към шлюз на сайт А -> Шлюз на сайт А изпраща пакети обратно към PC

Следователно е необходим този маршрут на политиката:

Входящи: ZyWall- Източник: "Подмрежата на сайт А" -> Дестинация: "Подмрежата на обект Б" - Следваща стъпка "VPN тунел на обект Б"

mceclip3.png

2.4 Тест чрез пингване на сървър/компютър

Тъй като компютърът е разположен в мрежата 192.168.20.0/24, а сървърът е разположен в мрежата 192.168.30.0/24, сървърът не разпознава мрежата 192.168.20.0/24 и затова е много вероятно да блокира ICMP пакети, идващи от непознати подмрежи. Следователно, когато извършвате тестове, винаги:

  • Деактивирайте вградената защитна стена (напр. Windows Defender / Firewall).
  • Деактивирайте други антивирусни програми и софтуери за защита на крайни точки, инсталирани на сървъра/компютъра.

mceclip11.png

Маршрутизиране на трафика от клиента към сайта чрез тунел от сайта към сайта

Внимание: Това не работи с Dynamic VPN! Моля, изберете само Site2Site VPN!

1.png

1) Конфигуриране на SecuExtender IPSec VPN

За да се маршрутизират IPSec VPN клиентите в друг тунел, те трябва да използват фиксирани IP адреси.

Ако е необходимо да се маршрутизират много различни клиенти, се препоръчва да се използват IP адреси, които са близки един до друг, така че да може да се създаде обхват. Така се намалява броят на необходимите маршрути.

Не е необходимо подмрежата, в която се намират IP адресите, да присъства на защитната стена.

Въведете фиксирания IP адрес на IPSec VPN клиента

2.png

2) Конфигуриране на маршрутизацията на защитната стена

В защитната стена преминете към

Configuration > Object > Address

и щракнете върху

Add

за да създадете обхвата за IPSec VPN клиентските IP адреси.

3.png

Сега можем да добавим необходимите маршрути под

Configuration > Network > Routing

с едно кликване върху

Add

4.png

2.1 Защитна стена на сайта A

Трябва да създадем два маршрута:

  • Един за изходящия трафик, т.е. от динамичния тунел VPN-клиент към отдалечената подмрежа през тунела от сайта към сайта.

5.png

  • Един за входящия трафик, т.е. от отдалечената подмрежа през тунела site-to-site в тунела VPN-клиент.

6.png

Новите маршрути трябва да изглеждат по следния начин:

7.png

Друг начин за преминаване на входящия трафик от отдалечената подмрежа през отдалечения VPN тунел е да активирате "асиметричен маршрут":

mceclip0.png

Това ще активира "триъгълния" маршрут, който кара защитната стена да разреши използването на асиметрична топология на маршрута в мрежата и да не нулира връзката, когато отговорът се върне.

2.2 Защитна стена на обект B

На отдалечения сайт може да се наложи да бъдат създадени подобни маршрути, така че устройството на главния сайт да знае как да обработва трафика от VPN-клиентите, идващи от филиала.

На главния сайт създаваме IP-обхват за отдалечените VPN-клиенти, за да можем да го използваме за маршрутизиране на трафика.

8.png

Сега създаваме съответните маршрути и в сайта на централата.

Един изходящ маршрут от подмрежата на централата през тунела между сайтовете към отдалечените VPN клиенти.

9.png

И един входящ маршрут, така че от обхвата на отдалечените VPN-клиенти през тунела site-to-site към локалната LAN на HQ. Ако трафикът се маршрутизира в локална подмрежа, избираме "Auto" като следващ скок, USG управлява това автоматично.

10.png

Маршрутите трябва да изглеждат по следния начин:

11.png

+++ Можете да закупите лицензи за вашите Zyxel VPN клиенти (SSL VPN, IPsec) с незабавна доставка с едно кликване: Zyxel Webstore +++

Статии в този раздел

Беше ли полезна тази статия?
1 от 7 считат материала за полезен
Споделяне