Алыскы колдонуучулар VPN хабы аркылуу экинчи сайтка жете алышпайт

Алыскы колдонуучу хабга туташып, хабдын өз LAN тармагындагы файл серверине жетет жана баары соо көрүнөт. Андан кийин ал башкы кеңседеги 10.20.0.50 дарегиндеги бөлүшүүнү ачат, ага хаб өзүнчө сайт-сайт туннели аркылуу жетет, бирок күтүү убактысы бүтөт. Эки туннел тең көтөрүлгөн жана эки эсептегич тең өсүп жатат, ошондуктан туннелдердин бири да бузулган эмес. Хабдан өтүү — үч түзүлүштөгү үч маршруттоо чечими, жана туннель өзү курулган префикстерди гана ташыйт. Бул — мен текшере турган тартип жана ар бир кадамдын тууралыгын көрсөткөн буйрук.

Өтүү үч издөөнү талап кылат, бир туннелди эмес

Ар бир түзүлүш өзүнүн эң узун префикс дал келүүсүн жасайт жана аны унутат. Ноутбук 10.20.0.50ни жергиликтүү маршрутизаторго эмес, туннелге жөнөтүшү керек. Хаб алыскы кирүү интерфейсине келген пакетти алып, аны сайт-сайт интерфейсине өткөрүшү керек. Башкы кеңсе колдонуучунун дарегине жоопту туннель аркылуу кайтарышы керек. Ушул үчөөнүн кайсынысы болбосун ишке ашпаса, браузерде бирдей көрүнөт: тынчтык.

Ошондуктан ар бир туннелди өзүнчө текшерүү өтө аз нерсени далилдейт. Хабдын LAN дарегине ping жасоо биринчи чечимди текшерет, ал эми башкы кеңседен хабга ping жасоо үчүнчүсүн текшерет. Ишке ашпаган пакеттин булагы колдонуучулар пулу, ал эми багыты экинчи сайт, ошондуктан алгач ошол префикстерди жазып алыңыз. Бул жерде пул — 10.80.0.0/24, хабдын LAN — 10.10.0.0/24, башкы кеңсе — 10.20.0.0/24.

Алыскы префиксти алыскы кардарга түртүңүз

Бир OpenVPN алыскы кирүү серверинде кардар туташуу учурунда маршруттарды үйрөнөт. push жок болсо, бөлүнгөн туннелдүү кардар 10.20.0.50ни өзүнүн дарбазасына жөнөтөт жана пакет туннелге эч качан кирбейт.

push "route 10.20.0.0 255.255.255.0"

Түртүлгөн маршрут кардар туташканда күчүнө кирет, ошондуктан онлайн бойдон калган колдонуучу кайра туташканга чейин эч нерсе көрбөйт. Кардарда текшериңиз: Linuxте ip route get 10.20.0.50, Windowsто route print. Чыгуу туннел интерфейсинин атын аташы керек.

push хабга жардам бербейт. Бул кардарга жөнөтүлгөн билдирүү, сервердеги маршрут да эмес, өткөрүү уруксаты да эмес, ошондуктан кемчиликсиз push сабы бар хаб да бир хоптон кийин агымды таштайт. Адамдар push ишке ашпады деп жыйынтык чыгаруусунун кадимки себеби ушул.

Хабга чыныгы чыгуу маршрутун бериңиз

Хабга башкы кеңсенин префикси үчүн өзүнүн кийинки хопу керек. Маршрутталган туннелде бул сайт-сайт интерфейси аркылуу өткөн кадимки маршрут, ал эми бир буйрук тандалган маршрутту да, тандалган булакты да көрсөтөт:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Сайт-сайт буту өзү OpenVPN болсо, маршрут ошол конфигурацияда өнөктөштүн туннель дарегин дарбаза катары кармап жашай алат: route 10.20.0.0 255.255.255.0 172.30.0.2. Дарбаза милдеттүү. Аны калтырып кетсеңиз, кийинки хоп ишке ашыруунун демейки маанисине түшөт, ал бир алыскы кардар менен бир нече өнөктөштүү хабдын ортосунда башкача.

Саясатка негизделген IPsec башкача: хабдын өзөгү пакетти кадимки LAN дарбазасына жөнөтөт жана саясат аны чыгуу жолунда кармайт, ошондуктан туннель маршруту же эч нерсе кылбайт, же трафикти саясатты айланып өткөрөт. Жогорудагы буйруктагы булакка көңүл буруңуз, анткени пулдун дарегинин ордуна 10.10.0.1 болсо, өзөк алыскы тарап четке кага турган даректти тандаган. iroute да жооп эмес; ал серверге кайсы кардар өз туннелинин артындагы кошумча тармакка ээ экенин айтат, үчүнчү сайт үчүн трафикти кайда жөнөтүүнү эмес.

Алыскы тарапты колдонуучулар пулуна чейин кеңейтиңиз

Башкы кеңсе хабдын LANын, 10.10.0.0/24тү мурунтан камтыйт. Колдонуучулар пулу — экинчи префикс жана ал селекторлордо да болушу керек, болбосо 10.80.0.25ке жөнөтүлгөн жоопту эч бир саясат камтыбайт. Ар бир өнөктөш өз тарабынан префикс топтомдорунун ошол эле түгөйүн атайт:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Бир түзүлүштүн local_ts — экинчисинин remote_ts. Хабдын блогун башкы кеңсеге көчүрүңүз, түгөй теңкерилет, ошондуктан энчилүү SA эч качан көтөрүлбөйт.

Эскирээк ipsec.conf синтаксиси үтүр менен бөлүнгөн leftsubnet колдонот. Иштеп жаткан коопсуздук бирикмеси келишилген селекторлорду сактайт, ошондуктан түзөтүүдөн кийин туннелди кайра орнотуңуз. 10:00дө өзгөртүлгөн селектор 09:40та көтөрүлгөн SAга каршы сыналса, дагы эле ишке ашпайт, ал эми конфигурация файлы бүт убакыт бою туура көрүнөт.

Андан кийин акыркы хопту текшериңиз. Алыскы четтеги ip route get 10.80.0.25 туннелге карай багытталышы керек. Эгер кызмат LAN маршрутизаторун демейки дарбаза катары колдонсо, ал маршрутизаторго да кайтуу маршруту керек, болбосо жооп ошол жерде өлөт. Ошол сегментте tcpdump -ni eth1 host 10.80.0.25 иштетүү жооптун четтен чыкканын көрсөтөт.

Хабда агымга уруксат бериңиз

Өткөрүү күйгүзүлүп, жол уруксат берилиши керек. Интерфейстердин ортосундагынын баарын кабыл алуунун ордуна эрежелерди эки префикске чектеңиз.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Кайтарылма жол чыпкасы — анын жанындагы тынч ишке ашпоочулук: эки бут түрдүү интерфейстерде болсо, rp_filter=1 жоопту таштай алат, ал эми кабыл алуу эрежесинин эсептегичи такыр кыймылдабайт. Аракеттен мурун жана кийин iptables -vnL FORWARD салыштырыңыз. Эч качан өспөгөн эрежеге жетпейт, ошондуктан аны кайра жазуунун ордуна бир катмар төмөн караңыз.

Эгер өтүү бир гана топко керек болсо, глобалдык pushты кеңейтүүнүн ордуна маршрутту client-config-dir астындагы ар бир кардардын файлына коюңуз. Хабдагы Source NAT да алыскы тараптын кайтуу маршрутунун керектигин жоёт, бирок ал колдонуучунун дарегин жашырат, ошондуктан алыскы сайттын журналдары жана дарекке негизделген эрежелер колдонуучуларды ажырата албай калат.

Кардардан текшериңиз, анан тескери тартипте артка кайтарыңыз

ICMP гана эмес, TCP портун сынаңыз, анткени ping өтүшү мүмкүн, ал эми кызмат жабык бойдон калат. Кардардан nc -vz 10.20.0.50 445 жана traceroute -n 10.20.0.50 экинчи хоп хабдын туннель дареги экенин көрсөтөт. Хабда tcpdump -ni tun0 host 10.20.0.50 жана сайт-сайт интерфейсиндеги ошол эле чыпка: экөөндө тең суроо бар, бирок эч кайсында жооп жок болсо, маселе алыскы тарапка өтөт.

Андан кийин жабык бойдон калышы керек нерсени сынаңыз. Эгер пул эч качан жетпеши керек болгон хост да жооп берсе, сиз өтүүдөн көбүрөөк ачкансыз жана эрежелерди тарылтуу керек. Баарын ар бир бутакка өткөргөн хаб биринчи сыноодон өтүп, экинчисинде ишке ашпайт.

Артка кайтаруу тизмесин кармаңыз, анткени төрт объект өзгөрдү жана үчөөнү унутуу оңой: түртүлгөн маршрут, хабдын маршруту, селекторлор жана тармак аралык экрандын эрежелери. Аларды тескери тартипте жокко чыгарыңыз, SAны кайра орнотуңуз жана бир колдонуучуга кайра туташууга уруксат бериңиз. Жарым-жартылай кайтаруу эми дал келбеген туннелге көрсөткөн маршрутту калтырат, аны окуу баштапкы тынчтыктан кыйыныраак. OpenVPN 2.6 боюнча колдонмо сиздин версияңыз үчүн push, route жана iroute документтейт.