Трыгераванне партоў супраць перанакіравання партоў для хатняга VPN-сервера

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

Два правілы з рознымі жыццёвымі цыкламі

NAT у IPv4 захоўвае стан. Калі ўнутраны хост адпраўляе пакет вонкі, маршрутызатар стварае адлюстраванне, каб адказы знайшлі шлях назад; уваходны пакет, які не адпавядае ніякаму адлюстраванню, адкідаецца, і менавіта гэта трымае неабноўлены камп’ютар па-за інтэрнэтам. Перанакіраванне — пастаянны запіс пераўтварэння, дададзены ўручную. Трыгераванне — часовы пракол, ахоўваемы малюнкам трафіку.

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

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

Чаму трыгераванне не апублікуе сервер

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

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

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

Што насамрэч адлюстроўвае перанакіраванне

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

Пратакол важнейшы, чым падказвае форма. OpenVPN праз UDP патрабуе перанакіравання UDP, WireGuard патрабуе UDP, а даныя IPsec прыходзяць як ESP, пратакол IP 50, які зусім не мае партоў. Форма перанакіравання, якая прымае толькі TCP або UDP, гэтага выказаць не можа, таму IPsec патрабуе passthrough або статычнага адзін-да-аднаго адлюстравання замест правіла порта.

Узровень над вашым маршрутызатарам

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

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

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

Абмяжуйце правіла, потым праверце абедзве паловы

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

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

Праверка мае дзве паловы. Handshake павінен завяршыцца з знешняй сеткі, а затым прыватны рэсурс за серверам павінен адказаць праз тунель. Перанакіраванне прапускае злучэнне тунеля і нічога больш; маршрутызацыя і аўтарызацыя для 10.8.0.0/24 — гэта іншая налада на іншым экране.

Вырашыце трыма пытаннямі

Тры пытанні вырашаюць выбар хутчэй за любую параўнальную табліцу:

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

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