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, щоб обидва шляхи можна було порівняти. Повторіть обидва після перезавантаження будь-якого з пристроїв.

Маршрути, додані вручну, і трансляції, які ніколи не зберігалися, зникають разом. Тоді пара виглядає як нова несправність, а не як незавершена робота.

Збережіть модель підключення разом із маршрутами, дозволеною приватною службою та будь-якою трансляцією в одній нотатці. Саме ця нотатка заважає наступній людині вважати бездротове розміщення питанням маршрутної політики.

Схожі статті