Remote Access
MikroTik IPsec Site-to-Site VPN наръчник
Изградете MikroTik IPsec site-to-site VPN: конфигурирайте IKEv2 peer, proposal, policy и NAT bypass правилото, което кара тунела да работи.
Резюме MikroTik IPsec site-to-site VPN криптира трафика между две цели мрежи — централен офис и клон, NOC и площадка с кула — така че хостовете във всяка LAN достигат другата, сякаш са локални. Това ръководство конфигурира и двата рутера с RouterOS v7: IKEv2 peer, identity с предварително споделен ключ, proposal за Фаза 2, policy на тунела, NAT bypass правилото, което проваля повечето първи опити, и правилата на защитната стена и проверките, потвърждаващи, че тунелът е активен.
Какво е MikroTik IPsec site-to-site VPN?
MikroTik IPsec site-to-site VPN е постоянен криптиран тунел между два рутера, който обединява две отделни LAN мрежи в една маршрутизируема мрежа на Слой 3, без нито един рутер да излага управляващ порт към публичния интернет. За разлика от клиентските VPN като WireGuard или OpenVPN — където се свързва едно администраторско устройство — тунелът site-to-site е постоянно активен и от подмрежа към подмрежа: всеки хост зад Рутер A може автоматично да достигне всеки разрешен хост зад Рутер B. IPsec е правилният избор тук, защото е отворен стандарт, поддържан от практически всеки производител на защитни стени и рутери, работи в ядрото на RouterOS за добра пропускателна способност, а в MikroTik е вграден без допълнителен пакет за инсталиране.
Тунелът се изгражда чрез две договаряния. Фаза 1 (IKE) удостоверява двата рутера един пред друг и създава защитен канал; Фаза 2 (IPsec) договаря ключовете, които реално криптират данните ви. Направете двете фази съвпадащи от всяка страна и тунелът се вдига; разминете един-единствен алгоритъм и той се проваля тихо — затова стъпките по-долу поддържат двете страни симетрични.
Преди да започнете
Нуждаете се от два MikroTik рутера с RouterOS v7, всеки с публичен IP адрес или работещо DDNS име, и две непокриващи се LAN подмрежи. Това ръководство използва 192.168.10.0/24 на Площадка A и 192.168.20.0/24 на Площадка B. Ако и двете площадки използват 192.168.88.0/24, маршрутизацията е невъзможна — първо преадресирайте едната страна. Тъй като IPsec е много чувствителен към разминаване на часовника, активирайте NTP и на двата рутера, преди да започнете; ако двата края се разминат, security associations изтичат и тунелът постоянно пада.
Управлението на това изискване върху повече от няколко площадки вече е тежест. Когато управлявате флот, MKController ви дава единна конзола, за да потвърдите версията на RouterOS и източника на часовник на всеки рутер, преди да превключите тунел, така че да не влизате във всяко устройство само за да проверите дали е готово.
Стъпка 1: Създайте IKE profile и peer
На Площадка A дефинирайте profile за Фаза 1 и насочете peer към публичния адрес на Площадка B:
/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \ enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d
/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \ profile=to-siteB exchange-mode=ike2dh-group=modp2048 е Diffie-Hellman Група 14 — солидна съвременна стойност по подразбиране. exchange-mode=ike2 избира IKEv2, който е по-бърз и по-надежден от остарелия режим main/IKEv1. И двата края трябва да използват едни и същи стойности на profile и един и същ режим на обмен.
Стъпка 2: Добавете identity (предварително споделен ключ)
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"Използвайте дълга, случайна тайна и я съхранявайте както бихте съхранили SSH ключ — не в чат съобщение. Същата тайна се поставя и на двата рутера.
Стъпка 3: Дефинирайте proposal за Фаза 2
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048Perfect Forward Secrecy (pfs-group) означава, че всяко подновяване на ключа използва свеж ключов материал, така че компрометиран ключ никога не разкрива минал трафик. Както при Фаза 1, алгоритмите трябва да съвпадат и от двете страни.
Стъпка 4: Създайте policy за тунела
Policy казва на RouterOS кой трафик да криптира — локалната LAN към отдалечената LAN:
/ip ipsec policy add peer=siteB tunnel=yes \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \ proposal=to-siteB action=encrypttunnel=yes е това, което прави връзката site-to-site, а не хост-към-хост: оригиналните пакети се обвиват цели, така че двете LAN мрежи да общуват прозрачно.
Стъпка 5: Добавете NAT bypass правилото (стъпката, която всички забравят)
Тук се провалят повечето първи опити. Вашият рутер вече има masquerade правило, което пренаписва адреса на източника на изходящия LAN трафик. Ако то се задейства преди IPsec, отдалеченият край получава пакети, чийто източник вече не съвпада с policy, и ги отхвърля. Добавете accept правило над masquerade, за да заобиколи NAT трафикът, предназначен за тунела:
/ip firewall nat add chain=srcnat action=accept place-before=0 \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24place-before=0 поставя правилото на самия връх на srcnat веригата, което е задължително — bypass правило, поставено след masquerade, не прави нищо.
Стъпка 6: Отворете защитната стена и проверете
Разрешете портовете за IKE и NAT-T плюс протокола ESP във веригата input, за да може тунелът да се установи, особено ако някоя от площадките е зад друго NAT устройство:
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept/ip firewall filter add chain=input protocol=ipsec-esp action=acceptСлед това потвърдете, че тунелът е активен:
/ip ipsec active-peers print/ip ipsec policy printЗдравият тунел показва активен peer и policy, чийто ph2-state е established. Бърз ping от хост в едната LAN към хост в другата доказва достъпност от край до край.
Огледално конфигуриране на Площадка B
Повторете всяка стъпка на Площадка B с разменени адреси: peer сочи към публичния IP на Площадка A, а policy и NAT bypass използват src-address=192.168.20.0/24 и dst-address=192.168.10.0/24. Profile, proposal, тайната на identity и режимът IKEv2 остават идентични. Когато двете страни съвпаднат, Фаза 1 и Фаза 2 приключват и тунелът се вдига.
Съвети за сигурност и експлоатация
Поддържайте RouterOS обновен — скорошни издания съдържат корекции, засягащи съпоставянето на peer сертификати в IPsec/IKEv2, така че тунел, работил миналото тримесечие, заслужава повторен тест след всяко обновяване. Предпочитайте IKEv2 с PFS пред остарелите настройки на IKEv1. Където е възможно, преминете от споделена тайна към удостоверяване със сертификати с нарастването на броя тунели, защото един изтекъл предварително споделен ключ засяга всяка площадка, която го споделя. И записвайте състоянието на тунела някъде, където наистина гледате: мъртва site-to-site връзка е невидима, докато някой не се опита да достигне отдалечената LAN и не успее.
При флот IPsec тунел, който тихо пада след разсинхронизиране на часовника или трепване на WAN, е точно видът повреда, който клиентът забелязва преди вас. MKController запълва тази празнина: наблюдава всеки рутер през защитен изходящ тунел, който не изисква публичен IP и пренасочване на портове на устройството, поддържа версионирани резервни копия на конфигурацията, за да можете да сравните и възстановите работещ IPsec блок след неудачна промяна, и може да отвори тикет при събитие link-down, преди телефонът да звънне. За самата конфигурация на тунела нашето ръководство за NAT в MikroTik обяснява masquerade правилото, което заобикаляте тук, а за достъп до един рутер, вместо обединяване на две LAN мрежи, вижте отдалечено управление зад CGNAT и нашето ръководство за отдалечено управление с WireGuard.
Съберете тунелите си на едно място
IPsec свързва две площадки чисто, но растящ ISP или MSP скоро има десетки тунели, ключове и правила на защитната стена за синхронизиране — и всяка ръчна промяна е шанс да се заключите извън отдалечена площадка. MKController е създаден точно за такъв мащаб: централизирано управление на флота, защитен отдалечен достъп без изложени портове, история и резервни копия на конфигурацията и промени на защитната стена и policy върху целия флот, така че шаблон за тунел се разгръща веднъж, вместо да се пренаписва рутер по рутер. Оператори, работещи с MikroTik в мащаб, го използват, за да превърнат изгубен следобед със SSH по устройства в няколко клика на промяна.