Адкрыццё порта VPN не дае кліентам доступу да LAN

Тунэль уздымаецца, кліент праходзіць аўтэнтыфікацыю, але LAN за шлюзам застаецца нябачнай. Правіла, якое павінна было гэта выправіць, дазваляе порт VPN і працуе менавіта так, як запісана, бо яно датычыцца пакетаў, адрасаваных самому шлюзу. Трафік кліента да хоста за шлюзам мае іншы пункт прызначэння і іншы ланцужок. Паспяховы ўваход не мяняе таго, які з двух ланцужкоў выбірае ядро.

Два ланцужкі, два розныя пункты прызначэння

Лёс пакета вызначае тое, куды ён ідзе, а не тое, як ён прыйшоў. Трафік на адрас шлюза дастаўляецца лакальна і правяраецца правіламі ўваходу. Трафік, які шлюз перасылае далей, правяраецца правіламі перасылкі. Адзін і той жа інтэрфейс тунэля можа ствараць абодва тыпы пакетаў, таму адно правіла не можа закрыць абедзве задачы.

Увесь міф у адным сказе: дазвол слухачу нічога не кажа пра дазвол сеткі за ім. Гэта два асобныя рашэнні з асобнымі доказамі, і імя інтэрфейса на абодвух не аб'ядноўвае іх.

Што насамрэч дазваляе правіла слухача

Пакеты слухача завяршаюцца ў працэсе VPN, і менавіта гэта дазваляе ўстанавіць тунэль. Старонка кіравання шлюзам і лакальны дыягнастычны адказ таксама выкарыстоўваюць уласны шлях уваходу хоста, таму праверка шлюза паспяховая, а ўсё за ім не працуе. Абодва вынікі правільныя, і ні адзін не пра LAN.

Калі працэс дэкапсулюе трафік кліента для іншага пункта прызначэння, пакет трапляе на шлях перасылкі і патрабуе дазволу там. Паспяховая аўтэнтыфікацыя вырашае, хто ёсць кліент; яна не вырашае, куды кліенту можна ісці. У двух пытанняў розныя ўладальнікі, розныя журналы і розныя паведамленні пра памылку.

Тэстуйце з кліента, ніколі са шлюза

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

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Калі запыт з'яўляецца на tun0, а да пункта прызначэння нічога не даходзіць, пакет адкідаецца пасля прыходу, што паказвае на правілы перасылкі або на ўласную фільтрацыю пункта прызначэння. Калі на tun0 не з'яўляецца нічога, кліент нават не адпраўляе яго ў тунэль, і праблема ў маршрутызацыі на кліенце, а не ў палітыцы на шлюзе. Параўнайце гэта з запытам, які правільна выходзіць і нічога не вяртае, што і ёсць выпадак зваротнага шляху.

Перасылка патрабуе трох рэчаў, а не адной

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Чытайце тры вынікі разам. Нуль у першым робіць астатнія два неістотнымі, а палітыка адмовы па змаўчанні ў другім адкідае пакеты кліента, пакуль уласны трафік шлюза працуе. Трэці вынік паказвае, чаму правіла слухача ніколі не было праблемай.

Трымайце два наборы правілаў асобна ў дакументацыі

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

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

Нарэшце, трымайце пласты роўна, калі карыстальніку адмаўляюць. Калі запыт даходзіць да хоста, а праграма адхіляе ўліковы запіс, выпраўце дазвол праграмы на гэтым пласце; пашырэнне перасылкі не можа даць уліковыя даныя для агульнага доступу да файлаў і пашырыць доступ для ўсіх астатніх, хто паспяхова падключыцца.