Pi VPN с няколко маршрутизатора: поставете всеки маршрут на устройството, което решава

Маршрутизатор надолу по веригата добавя втора клиентска подмрежа и всяко от четирите устройства притежава едно решение. Поставете маршрутите, проверете източника, след което тествайте от реален клиент.

Поставянето на Wi-Fi кутия зад Pi превръща едно маршрутно решение в четири и планът се чупи, когато и четирите се вземат на едно устройство. Първият въпрос не е кой маршрут да се добави. А дали новата кутия мост или маршрутизира, защото този отговор определя колко подмрежи съществуват и кои устройства трябва да научат за тях. Изберете първо модела на свързване; всеки маршрут следва от него.

Мост или маршрутизиране: изборът, който определя броя

Мостът поставя новите клиенти в същата подмрежа, която Pi вече обслужва. Една подмрежа, един DHCP авторитет и никакво предаване за маршрутизиране. Това е по-простата схема и правилната, когато отделна клиентска мрежа никога не е била изискване. Маршрутизираната връзка е различен дизайн: кутията запазва своята подмрежа и този префикс трябва да се носи навсякъде, където отива трафикът.

Останалата част от плана запазва маршрутизатора надолу по веригата и съхранява клиентските адреси на източника. Целта е една частна VPN мрежа, а не пълен интернет изход. Запишете модела преди адресите, защото списъкът по-долу е само пример за маршрутизирано свързване.

client subnet       10.41.0.0/24
client gateway      10.41.0.1
router-to-Pi link   192.168.71.2
Pi on that link     192.168.71.1
private target      10.72.9.0/24

Кой какво решава

Decision ownerEntry that encodes the decisionFailure when the entry is missing
Pi VPN hostReturn route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24Replies to downstream clients die at the Pi
Owner of the remote networkA path for 10.41.0.0/24 over the permitted tunnelReplies stop at the first unaware hop
LAN router behind the PiSpecific route for 10.72.9.0/24 via 192.168.71.1, or a suitable defaultClients never send private traffic to the Pi
Client machineDefault via 10.41.0.1, or a specific entry for 10.72.9.0/24The private network is unreachable from the client

Всяко устройство взема едно решение и никое не може да вземе чуждото вместо него. Pi се нуждае от два записа, не от един, а обратният път е този, който хората забравят. Препратеният трафик достига правилно до частната мрежа и след това умира по пътя назад, защото Pi няма представа къде живее 10.41.0.0/24. Това изглежда като проблем с защитната стена и всъщност е липсващ маршрут.

Отдалечената страна също се нуждае от свой маршрут. Ако услугата в далечния край не знае, че 10.41.0.0/24 е достъпна през вашия тунел, отговорите спират при първия хоп без отговор. Добавете двете посоки, преди да четете филтри за пакети.

Следващите хопове идват от свързването

Следващият хоп трябва да е адрес в мрежа, до която устройството наистина може да достигне. Публичният адрес на VPN партньора не е следващият хоп за частна подмрежа, а далечната мрежа на услугата изобщо не е следващ хоп. Маршрут към недостъпен шлюз изглежда правилен в списък и изпуска всеки пакет. Проверете дали шлюзът отговаря, преди да обвинявате дестинацията.

Пазете външния VPN партньор на Pi достъпен през собствения му подлежащ маршрут. Този запис е отделен от маршрутите за полезния товар и смесването им дава тунел, който не може да се възстанови след промяна на пътя.

Документацията за статични маршрути прави разликата между дестинация и шлюз ясна, макар всяка платформа да именува менютата си различно. Четете документацията за устройството пред вас, вместо да копирате екрана на друг доставчик. Командите по-долу показват формата на записите в Linux.

# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1

Какво прави преводът с източника

Ако маршрутизаторът надолу по веригата вече превежда клиентите си към транзитния адрес, Pi вижда един преведен източник вместо собствения адрес на всеки клиент. Това е различен дизайн от запазващия източника по-горе. Променя политиката, базирана на източник, регистрирането и коя страна може да инициира връзки. И двата дизайна работят; те отговарят на различни въпроси.

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

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

Докажете го от клиентска машина

Изпратете заявка от машина в долната LAN, след което проследете източника ѝ навън и обратно. Ping, издаден от Pi, никога не упражнява обратния маршрут надолу и затова успешният ping доказва по-малко, отколкото изглежда. Добавете втори тест от кабелен клиент в собствената LAN на Pi, за да могат двата пътя да се сравнят. Повторете и двата след рестартиране на което и да е устройство.

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

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

Подобни статии