Еден OpenVPN центар, три LAN мрежи: план на адреси и iroute датотеки

Четири непресечни префикси, еден кернелски маршрут по гранка, еден iroute по сопственик. Работен ред за центар со три локации што тивко откажува кога името е погрешно.

Три приватни LAN мрежи можат да се сретнат на еден центар без ниту една локација да ги знае внатрешностите на другите, и целиот дизајн почива на четири кратки конфигурациски одлуки. Она што го прави да работи не е егзотична протоколска функција, туку план на адреси што никој не мора да го погодува, плус маршрути по клиент што му кажуваат на центарот која гранка поседува кој префикс. Ако едно од тие две е погрешно, тунелот сепак се крева, и токму тоа го прави дефектот збунувачки.

Поминете ги чекорите по ред. Секој зависи од планот од претходниот чекор, и ниту еден не бара ново сертификациско тело.

Започнете со план што никој не мора да го погодува

Запишете четири непресечни префикси пред да допрете конфигурациска датотека: LAN мрежата на самиот центар, LAN мрежата на секоја гранка и базенот што им се дава на клиентите во движење. Непресечноста е она што сето друго го држи едноставно, бидејќи преклопените опсези го претвораат рутирањето во загатка со најдолго совпаѓање што не може да ја поправи никаква конфигурација по клиент. Потоа проверете кој уред е стандардната порта за секоја LAN, бидејќи рутерот на гранка што не е порта на својата LAN треба да ги инсталира далечинските маршрути сосема на друго место. На крај, утврдете ги автентицираните имиња што ја идентификуваат секоја гранка, бидејќи тие имиња се клучевите по кои се пребаруваат датотеките по клиент.

Илустративниот план го држи базенот доста далеку од трите LAN мрежи. Вашиот ќе биде поинаков, и единственото строго правило е дека ниту два опсега не смеат да се преклопуваат.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Кажете му на кернелот на центарот каде се гранките

На центарот му требаат две информации по гранка: кернелски маршрут што го испраќа префиксот во тунелскиот уред и iroute запис што му кажува на OpenVPN процесот кој клиент го поседува. Само кернелскиот маршрут ги доставува пакетите до тунелот и застанува таму, бидејќи демонот сето уште треба да одлучи кој партнер треба да ги прими. Само iroute записот ги остава тие пакети во кернелот без маршрут по кој да се оди. Двете линии припаѓаат на конфигурацијата што демонот навистина ја вчитува, и вреди да се провери пред да се дебагира било што друго.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Држете го client-to-client исклучено кога кернелот треба да биде точката за спроведување на правилата. Таа опција го препраќа сообраќајот меѓу партнерите внатре во демонот, што е погодно и исто така значи дека вашите правила за проследување никогаш не го гледаат текот. Сето подолу претпоставува дека кернелот го гледа секој пакет меѓу гранките.

Дајте ѝ на секоја гранка маршрутите што ѝ се потребни

На секоја гранка ѝ требаат маршрути до другите гранки и до LAN мрежата на центарот, а не ѝ треба маршрут до сопствената поврзана LAN. Далечинските префикси туркајте ги од центарот наместо да ги лепите во секој рутер, така четвртата локација подоцна ќе значи една нова датотека по клиент наместо четири измени. Датотеката по клиент ја содржи и линијата iroute, што ги држи сопственоста и објавувањето на исто место. Направете ја директориумот и неговите датотеки читливи според моделот на привилегии на серверот, инаку пребарувањето не успева без порака.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Четвртата локација го следи истиот образец: посебно автентицирано име, поседуван префикс, кернелски маршрут на центарот, iroute запис и објавувања само до локациите што смеат да ја достигнат.

Тестирајте во двете насоки пред да го прогласите за готово

Овозможете IPv4 проследување на сите три рутери, потоа потврдете дека огнениот ѕид ги дозволува предвидените текови во двете насоки, бидејќи еднонасочен тест поминува со скршен повратен пат почесто отколку што некој очекува. Помеѓу локациите не е потребно преведување на изворната адреса, и токму зачувувањето на оригиналниот извор ѝ овозможува на секоја гранка да примени сопствена политика врз барањето.

Тестирајте од домаќин на една гранкова LAN до услуга на друга, потоа сменете го правецот, потоа тестирајте од гранка до LAN мрежата на центарот. Тие три резултати се различни докази, и ниту еден не ги подразбира другите. Ако рутерот на гранка не е стандардната порта на својата LAN, инсталирајте ги далечинските префикси на вистинската порта и вклучете го и базенот кога клиентите на тунелот треба да започнат врски во таа LAN.

Запишете ги планот, датотеките по клиент и правилата на огнениот ѕид како еден документ, бидејќи следното додавање локација ќе се оценува според нив.

Дизајнот се држи заедно затоа што секој слој има една задача: планот ги држи префиксите единствени, кернелскиот маршрут ги движи пакетите, iroute го именува сопственикот, а огнениот ѕид одлучува што е дозволено. Кога нешто ќе се расипе, тој список е и редот за проверка.

Поврзани статии