Објавите клијентски порт VPN-а иза CGNAT-а: контролна листа

Поставите услугу на преносни рачунар иза NAT-а на нивоу оператера, усмерите тај рачунар на VPS преко VPN-а и нико са стране не може да му приступи. Додате правило одредишног NAT-а на VPS и добијете нешто горе од тишине: везе се отварају, а затим застају. Одговор не недостаје, он излази клијентовом сопственом подразумеваном рутом, што значи да га сервер никада не види. Прођите кроз ових пет провера по реду и зауставите се на првој која не стоји.

Потврдите да ће сервер уопште прослеђивати

Означите овај оквир пре него што напишете и један превод. Правило DNAT-а за пакет који језгро одбија да проследи прихвата парсер правила, а затим га одбацује путања прослеђивања, што даје истек који изгледа као проблем са заштитним зидом.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Постављање у језгру које ради није исто као постављање кроз поновно покретање. Запишите net.ipv4.ip_forward=1 у датотеку под /etc/sysctl.d/, покрените sysctl --system, па прочитајте вредност назад уместо да верујете да је датотека преузета. Контејнер који управља сопственим мрежним простором имена треба исту вредност унутар тог простора, не само на хосту.

Ако је очитавање и даље нула, зауставите се овде. Ништа даље неће радити.

Фиксирајте адресу тунела пре него што се на њу позове иједно правило

Базен додељује адресе по реду повезивања, па правило написано за данашњи закуп може тихо да показује на другог клијента следеће недеље. Вежите адресу за идентитет сертификата, а не за редослед доласка.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Тај пар је клијентски крај и крај партнера тунела тачка-тачка, а сервер је везан за заједничко име сертификата. У топологији подмреже друга вредност се чита као мрежна маска, па напишите облик који одговара топологији у употреби. Затим поново повежите клијента и прочитајте адресу на самом клијенту, јер поглед сервера на базен није доказ шта је клијент конфигурисао.

Ако се адреса промени после поновног повезивања, зауставите се. Правило NAT-а које следи покретну мету неће успети с прекидима и неће вас ничему научити.

Преведите у оба смера

Превод одредишта шаље долазни пакет клијенту. Превод извора је оно што тера клијента да одговори серверу, а не изворном пошиљаоцу, и то је правило које људи изостављају.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

Без другог правила клијент одговара кроз свој ISP узлазни канал, па удаљени партнер види изворну адресу са којом никада није разговарао, док сервер не држи никакав запис праћења за одговор. Спољни посматрач види руковање које се довршава на пола, а то је управо симптом који шаље људе у потрагу за грешком у заштитном зиду које нема.

Прочитајте оба правила назад помоћу iptables -t nat -S и потврдите да је назив интерфејса онај који носи јавну адресу. На хосту који већ филтрира помоћу nftables, упишите превод у nftables NAT ланац одговарајуће породице адреса уместо да мешате алате.

Пустите табелу филтера кроз

NAT табеле преписују заглавља; оне не дају дозволу. Са подразумеваном политиком DROP прослеђени ток треба сопствено прихватање, плус повратни смер који већина политика већ покрива правилом established,related.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Проверите политику ланца FORWARD пре него што било шта додате, јер редослед раног DROP одлучује да ли ће ваше правило уопште бити размотрено. На хосту чије филтрирање живи у nftables, додајте еквивалентно правило на forward куку табеле inet и потврдите да основни ланац заиста види прослеђени саобраћај, а не само локални улаз. Ако бројач пакета на новом правилу остане на нули док NAT бројачи расту, пакет се одбацује пре вашег правила. То је сигнал да прочитате редослед ланаца, не да додате другу копију истог правила.

Докажите то са спољне мреже

Тестирајте са неповезане мреже. Провера са другог рачунара на истом LAN-у може проћи кроз hairpin NAT подршку и никада не вежба путању коју користи удаљени клијент, па зелени резултат тамо доказује погрешну ствар.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Покрените снимање на серверу и на клијенту истовремено. Снимање на серверу показује да ли преведени пакет излази ка тунелу; снимање на клијенту показује да ли захтев пристиже и где је одговор адресиран. Запис о преводу у conntrack -L доказује да се правило подударило, а његово одсуство доказује да пакет никада није стигао до NAT ланца.

Скенери портова су слаб доказ. Пријављују порт као затворен док се апликација не веже и не почне да слуша, зато користите праву везу са правом услугом. Када коначно проради, задржите изложеност на том једном порту: прослеђивање SSH-а или административног панела зато што је прво правило деловало незгодно много је већа одлука од објављивања услуге.