RRAS сървър

За възприемането на тази част, приемаме, че имате понятие от мрежи. Започваме с малко теория. RRAS (Remote Routing Access Services). Тази роля е нужна за маршрутизация и отдалечен достъп. Тя изпълнява следните функции: LAN Routing, NAT+PAT, VPN, Site To Site VPN, Dial UP, както един модерен рутер. Дайте да разгледаме схемата по която ще направим упражнението.

Схемата както виждате не се е променила много. Същите компютри, играещи същата роля. Обърнете внимание на IP адресите. В предните упражнения маската беше /16, а не както тук /24. Променете IP адресите, както са на снимката. Нека да ги уточним. CORE Интерфейс Internet; IP=10.25.0.110/24; GW=IP=10.25.0.1; DNS=8.8.8.8; Metric=20 Интерфейс LAN0; IP=192.168.0.1/24; DNS=192.168.0.2; Metric=10 Интерфейс LAN10; IP=192.168.10.1/24; DNS=192.168.10.2; Metric=15 TLan-DC-01 Интерфейс LAN; IP=192.168.0.2/24; GW=192.168.0.1; DNS=192.168.0.2 TLan-DC-10 Интерфейс LAN; IP=192.168.10.2/24; GW=192.168.10.1; DNS=192.168.10.2 WIN81-E-X86 Интерфейс LAN; IP=192.168.0.50/24; GW=192.168.0.1; DNS=192.168.0.2 След като всичко е направено се прехвърляме на компютъра CORE. Да проверим настройката на интерфейсите. Влизаме в Command Prompt.

C:\Windows\system32>ipconfig Windows IP Configuration Host Name . . . . . . . . . . . . : CORE Primary Dns Suffix . . . . . . . : TLan.Net Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : TLan.Net Ethernet adapter LAN0: IPv4 Address. . . . . . . . . . . : 192.168.0.1(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 192.168.0.2 Ethernet adapter LAN10: IPv4 Address. . . . . . . . . . . : 192.168.10.1(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 192.168.10.2 Ethernet adapter Internet: IPv4 Address. . . . . . . . . . . : 10.25.0.110(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.248.0 Default Gateway . . . . . . . . . : 10.25.0.1 DNS Servers . . . . . . . . . . . : 8.8.8.8

Всичко е както на схемата. Задачата е, потребителите да получат Internet. Освен това потребители през Internet да могат да постъпят домейна. За целта RRAS сървъра трябва да изпълнява LAN Routing, NAT+PAT, VPN. Започваме с инсталиране на ролята.

Ролята ще се инсталира на компютъра CORE.

Ролята се казва Remote Access.

Предлага да изберем какви компоненти да има ролята. - DirectAccess and VPN (RAS): За да може да се изграждат VPN връзки. - Routing: Да може да рутира вътрешните мрежи, в случая 192.168.0.0/24 и 192.168.10.0/24 - Web Application Proxy: Този компонент прави минимални филтрации когато през Интернет се обръщат към WEB сървъра ни. Избираме Routing, това автоматично прави избор и на DirectAccess.

Виждате избраха се двата компонента.

За сега нищо не променяме.

Начало на самата инсталация.

Иска рестарт на компютъра. Да го направим за да влязат промените в сила. Това, че инсталирахме ролята, не означава, че CORE може да рутира, да прави NAT и VPN. За да се случи това първо трябва да настроим ролята.

За управление на ролята се ползват Remote Access Management и Routing and Remote Access. Избираме Routing and Remote Access.

За да изпълнява своите функции трябва да извършим първоначална конфигурация.

Предлага някои готови сценарии на работа. Нас готови сценарии не ни вълнуват затова избираме Custom configuration.

Това което ни трябва е: - Клиентите да достъпват домейна от Интернет през VPN, - Клиентите от вътрешната мрежа да могат да ползват Интернет, - Ако имаме няколко вътрешни мрежи да може да се рутират помежду си.

Да видим какво сътворихме.

- Рутера ще рутира не само вътрешната мрежа (LAN and demand-dial routing), - IPv6 няма да ползваме, - IPv4 Remote access server: Включен. Означава, че ще може да рутира и VPN клиентите. Да се прехвърлим на компютъра TLan-DC-01. Отваряме Command Prompt. C:\Windows\system32>ipconfig Windows IP Configuration Ethernet adapter Ethernet0: Connection-specific DNS Suffix . : IPv4 Address. . . . . . . . . . . : 192.168.0.2 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.0.1 Да се пробваме да достъпим TLan-DC-02. C:\Windows\system32>ping TLan-DC-02 Pinging TLan-DC-02.TLan.Net [192.168.10.2] with 32 bytes of data: Reply from 192.168.10.2: bytes=32 time< 1ms TTL=127 Reply from 192.168.10.2: bytes=32 time=1ms TTL=127 Reply from 192.168.10.2: bytes=32 time=2ms TTL=127 Reply from 192.168.10.2: bytes=32 time=1ms TTL=127 Ping statistics for 192.168.10.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 2ms, Average = 1ms Всичко работи. Да се уверим, че работи като се рутира през CORE. C:\Windows\system32>tracert -d TLan-DC-02 Tracing route to TLan-DC-02.TLan.Net [192.168.10.2] over a maximum of 30 hops: 1 < 1 ms * <1 ms 192.168.0.1 2 1 ms 1 ms 1 ms 192.168.10.2 Виждаме, че първата стъпка е през рутера CORE и след това се обръща към TLan-DC-02. По този начин създадохме рутиране между мрежите които имаме. Сега да направим така, че клиентите от вътрешната мрежа да могат да излизат в Интернет. Първо да се убедим, че за сега нямат. C:\Windows\system32>ping 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), За сега нямат достъп. Връщаме се на компютъра CORE.

Ако NAT-a го нямаше, можеше от тук да се добави. В случая обаче го имаме затова:

Добавяме интерфейсите върху които ще изграждаме NAT-a.

Първо добавяме интерфейса който ще гледа към Интернет-а.

Казваме, че интерфейса ще е вързан към публичната мрежа и върху него ще дефинираме NAT.

От тук може да укажем как от Интернет да се достъпи някоя вътрешна услуга, примерно FTP сървъра, който се намира в DMZ. Достъпа до RDP също се прави от тук.

Първия интерфейс е дефиниран. За да завършим конфигурацията трябва да вкараме и другите два интерфейса (от вътрешната мрежа).

Забележете как е дефиниран интерфейса. Част от частната мрежа. По същия начин и другия интерфейс

Готово, всички интерфейси са вкарани. Да проверим. Връщаме се на TLan-DC-01. C:\Windows\system32>ping 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=22ms TTL=55 Reply from 8.8.8.8: bytes=32 time=22ms TTL=55 Reply from 8.8.8.8: bytes=32 time=22ms TTL=55 Reply from 8.8.8.8: bytes=32 time=22ms TTL=55 Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 22ms, Maximum = 22ms, Average = 22ms Супер и NAT-a работи.

Настройка на VPN

Има няколко начина за изграждане на VPN връзка - PPTP: Много прост и не обезопасен протокол. Ползва порт 1723. В практиката рядко се ползва. - L2PT: По актуален, но сложен в настройването. - SSTP: Много добър вариант, но е протокол на Windows. Използването му с други операционни системи няма как да стане. Ползва порт 443. Може да се дигне защитна стена. Да се освободят стандартно портове 80 и 443, и тогава и VPN може да се вдигне. Влизаме в CORE.

Да дефинираме какви протоколи ще работят за VPN

PPPOE не ползваме, да го деактивираме.

SSTP също го изключваме, защото нямаме сертификат, а протокола работи със SSL сетификат

Също го изключваме.

Ще ползваме PPTP. Поради факта, че лесно се демонстрира с него се отказваме от другите варианти. Важно е да се разбере работата на VPN, а не на самия протокол - Remote access connections: Позволява да се свържем отдалечено. Активираме избора, - Demand-dial routing connections: Рутрира клиентите от Интернет във вътрешната мрежа използвайки RRAS сървъра. Активираме избора, - Maximum ports: Определя максималното количество клиенти които могат да правят VPN връзка през този протокол. Да ги ограничим до 16 клиента.

Педупреждава ни, че сме променили броя на конекциите през протокола. На нас за демонстрацията 16 връзки са ни достатъчни.

Отказваме се и от GRE протокола. Самия протокол е много гъвкав. В комбинация примерно с IPSec може да направи чудеса.

Крайния резултат е горепоказания.

Поглеждайки портовете, виждаме 16 възможни връзки през PPTP, които в момента са неактивни, поради факта, че яма вързан клиент през PPTP протокола. Сега да определим как клиента да се удостоверява в домейна през VPN-a. Има два пътя. Удостоверението го дава RRAS сървъра. Пример: Клиента се връзва към RASS сървъра през VPN с име и парола. Името и паролата се проверяват в активната директория. Ако ги има RASS сървъра позволява на клиента да се върже към активната директория. Значи пътя е следния. Клиента с име и парола запитва RASS сървъра. RASS сървъра се обръща към домейн контролера да провери дали са верни. Домейн контролера отговаря за истинността на името и паролата. В зависимост от истинността RASS сървъра или позволява или забранява достъпа на клиента до активната директория. Втори начин. Ползването на RADIUS сървър. Разликата от горния начин е, че между RASS сървъра и домейн контролера стои RADIUS сървъра. Тогава пътя е следния: Клиент > RASS сървър > RADIUS сървър > DC > RADIUS сървър > RASS сървър > Отговор на клиента. Имайки в предвид горе казаното да изградим една VPN връзка.

Имаме два начина на удостоверяване: RADIUS Authentication и Windows Authentication. Тъй като нямаме изграден RADIUS сървър ползваме Windows Authentication. Същото повтаряме и във втория прозорец, той се отнася за изграждане на статистика. Тук се прави запис дали сме се вързали успешно или неуспешно, колко пъти и т.н. По-надолу казваме, че няма да позволяваме IPsec за L2TP. Нали не използваме този протокол. Още по надолу не използваме и SSL сертификати за SSTP протокола.

Внимавайте да няма тук отметка. Това ще позволи на всички да се вържат в активната директория без да иска да се удостоверят (няма да проверява за истинността на името и паролата). Сега да укажем какви IP адреси да се раздават на клиентите.

Казахме само 16 клиента могат да се връзват през VPN-a, значи пула е от 16 адреса. Сега да укажем кой потребител може да ползва VPN връзка. Прехвърляме се на TLan-DC-01.

Ако имахме RADIUS сървър щяхме да използваме Control access through NPS Network Policy. Тъй като нямаме избираме Allow access. Да направим тест. За целта в 10.25.0.0/24 слагаме една машина и имитираме че сме в Интернет. През нея ще се помъчим да се вържем към активната директория през VPN. Да проверим мрежовите и настройки Прехвъляме се на машината от Интернет. C:\Windows\system32>ipconfig Ethernet adapter Ethernet0: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::1542:86d:7594:1313%6 IPv4 Address. . . . . . . . . . . : 10.25.0.89 Subnet Mask . . . . . . . . . . . : 255.255.248.0 Default Gateway . . . . . . . . . : 10.25.0.1 Да се пробваме сега да достъпим някой от домейн контролерите. C:\Windows\system32>ping 192.168.10.2 Pinging 192.168.10.2 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 192.168.10.2: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Не става, защото нямаме дигнат VPN тунел. Да го изградим.

VPN-a е създаден. Да го стартираме.

Свързахме се с CORE по VPN. Да проверим виждаме ли домейн контролерите. C:\Windows\system32>ping 192.168.0.2 Pinging 192.168.0.2 with 32 bytes of data: Reply from 192.168.0.2: bytes=32 time< 1ms TTL=127 Reply from 192.168.0.2: bytes=32 time=2ms TTL=127 Reply from 192.168.0.2: bytes=32 time=2ms TTL=127 Reply from 192.168.0.2: bytes=32 time=2ms TTL=127 Ping statistics for 192.168.0.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 2ms, Average = 1ms C:\Windows\system32>ping 192.168.10.2 Pinging 192.168.10.2 with 32 bytes of data: Reply from 192.168.10.2: bytes=32 time< 1ms TTL=127 Reply from 192.168.10.2: bytes=32 time=1ms TTL=127 Reply from 192.168.10.2: bytes=32 time=3ms TTL=127 Reply from 192.168.10.2: bytes=32 time=2ms TTL=127 Ping statistics for 192.168.10.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 3ms, Average = 1ms Достъпваме и двата домейн контролера. Да проверим сега какъв интерфейс се създаде и какво IP придоби. C:\Windows\system32>ipconfig Ethernet adapter Ethernet0: IPv4 Address. . . . . . . . . . . : 10.25.0.89 Subnet Mask . . . . . . . . . . . : 255.255.248.0 Default Gateway . . . . . . . . . : 10.25.0.1 PPP adapter CORE-VPN: IPv4 Address. . . . . . . . . . . : 172.16.0.2 Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : 0.0.0.0 Всичко това означава, че сме създали нов интерфейс CORE-VPN. Получил е IP от пула който зададохме. IP адресите от пула се рутират във вътрешната мрежа. По такъв начин имаме достъп до домейн контролерите, както и до всички компютри от вътрешната мрежа. Дайте сега да видим в RRAS сървъра какво се случи. Прехвърляме се на компютъра CORE.

Единия от портовете е активен.

Цъкаме с десен бутон на мишката и избираме Status….

Показва кой се вързал, какво IP му е дал и т.н. Съответно от тук може да се разбие връзката.

Тъй като през портовете е по неудобно да се разглежда кой се свързвал през VPN, от тук може нагледно да се видят връзките. Разбира се може да се разглежда и статуса на връзката, както разглеждахме през портовете. С това приключваме темата. Както виждате всичко това е тясно свързано с разбиране работата на мрежата, затова е добре да бъдете подготвени в тази област. Наново търсете през търсачките да повече информация или ми пишете на https://www.facebook.com/tachkot.