Шматмаршрутны 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, каб можна было параўнаць два шляхі. Паўтарыце абодва пасля перазагрузкі любой прылады.

Маршруты, дададзеныя ўручную, і пераклады, якія ніколі не захоўваліся, знікаюць разам. Пара тады выглядае як новы непалад, а не як незавершаная праца.

Захавайце мадэль далучэння разам з маршрутамі, дазволенай прыватнай службай і любым перакладам у адной нататцы. Гэтая нататка — тое, што не дае наступнаму чалавеку разглядаць размяшчэнне бесправадной сеткі як пытанне маршрутнай палітыкі.

Падобныя артыкулы