VPN на маршрутызатары ці перанакіраванне порта: што перамагае?

Маршрутызатар сам завяршае VPN, а старое правіла перанакіравання ўсё яшчэ адпраўляе той жа порт UDP на машыну ў лакальнай сетцы. Толькі адно з гэтага можа быць сапраўдным канчатковым пунктам, і ядро не вырашае паміж імі. Трансляцыя прызначэння перапісвае пакет да таго, як звернуцца да лакальнай службы, таму працэс VPN чакае трафік, які ўжо адпраўлены ў іншае месца. Задача — вызначыць, каму належыць порт, а затым узгадніць правілы.

Адзін порт, два заяўленыя ўладальнікі

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

Запішыце прэтэнзію перад рэдагаваннем: сямейства, знешні адрас, транспарт, порт і перакладзены аб’ект.

Трансляцыя ідзе перад лакальнай праверкай

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

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

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

Калі хост лакальнай сеткі — мэтавы канчатковы пункт, перанакіраванне правільнае, і маршрутызатар не павінен таксама слухаць гэты порт.

Пакіньце адно адлюстраванне і выдаліце другое

Пералічыце запісы NAT для гэтага порта і сямейства і выберыце таго, хто застанецца:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

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

Калі VPN жыве на асобным хосце, перанакіраванне — правільны аб’ект. Службе ў кантэйнеры або віртуальнай машыне можа спатрэбіцца апублікаваны порт, нават калі скрыня называецца маршрутызатарам, таму прасочвайце сокет і яго прастору імёнаў, а не этыкетку на корпусе.

Пацвердзіце ўладальніка звонку

Правярайце кожнае сямейства асобна, бо злучэнне IPv6, якое завяршаецца на маршрутызатары, нічога не кажа пра злучэнне IPv4, якое перанакіроўвае састарэлае правіла. Чытайце журнал службы, якая прымае, каб убачыць, які канчатковы пункт адказаў, і лічыце паведамленне кліента пра поспех слабым доказам. Для змястоўнай праверкі патрэбен новы паток. Адпраўце зонд з знешняга хоста з дапамогай nc -zvu 203.0.113.7 1194 і прачытайце журнал пераможцы з дапамогай journalctl -u openvpn@server -n 20. Слухач маршрутызатара запісвае злучэнне сам, а хост лакальнай сеткі запісвае яго ў сваёй службе.

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

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