Објавете 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 или административен панел затоа што првото правило изгледаше незгодно е далеку поголема одлука отколку објавување услуга.