Дали треба да примените SNAT на пренасочување порта во VPN подмрежа?

Пренасочувањето порта кон домаќин што стои зад сопствениот VPN клиент на рутерот не успева на начин што изгледа како проблем со заштитен ѕид, затоа што барањето очигледно пристигнува. Услугата регистрира врска, клиентот чека и ништо не се враќа. Преведувањето на одредиштето ја заврши својата работа; повратниот пакет е делот што исчезна. Едно селективно правило за изворен NAT на рутерот го поправа ова, а интересниот дел е да се одлучи колку тесно може да биде тоа правило.

Зошто одговорот оди по друг пат

Пренасочувањето порта го препишува каде оди пакетот, никогаш од каде дошол. Адресата на интернет клиентот останува во полето за извор по целиот пат низ тунелот, па далечната услуга гледа странец и одговара на единствениот начин што го знае: преку својот стандарден портал. Тој портал е VPN концентраторот од другата страна, кој нема маршрута назад кон произволна јавна адреса.

Гледајте снимка на интерфејсот на тунелот и асиметријата е очигледна: пакетите на барањето излегуваат, внатре ништо не доаѓа. Синџирот за пренасочување го дозволи текот и тунелот го пренесе, па отфрлањето се случува откако далечниот домаќин веќе избрал повратен пат.

Правило за извор доволно тесно за да му се верува

Направете го рутерот изворот на кој одговара далечниот домаќин. Во овој распоред WAN адресата е 203.0.113.24, LAN е 192.168.88.0/24, адресата на тунелот на рутерот е 172.20.5.1, а услугата одговара на 172.20.5.40:8443. Правилото подолу се совпаѓа со пакетот по преведувањето на одредиштето, затоа ја именува преведената адреса, а не јавната. Ништо во него не зависи од адресата на клиентот, и токму тоа е поентата.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Секое совпаѓање во тој ред постои за да го задржи препишувањето локално за една услуга на еден тунел. Отстранете го интерфејсот или портата и препишувате повеќе сообраќај отколку што бара проблемот, и така насочената поправка станува мистерија за следниот човек.

Кога сеопфатната маскарада е чесниот избор

Ако рутерот пренасочува многу услуги во истата VPN подмрежа, правилото по услуга станува список што никој не го одржува. Маскирањето на сѐ што излегува од интерфејсот на тунелот е поедноставно и предвидливо, по цена да се сокрие оригиналниот клиент од секој домаќин на другата страна. Изберете го кога тамошните дневници не се користат за припишување; задржете го тесното правило кога се користат.

Двете опции и не успеваат различно. Правилото што недостасува крши една услуга; широката маскарада што совпаѓа премногу може тивко да препише сообраќај што веќе работел, вклучително и сопствените излезни врски на рутерот.

Проверете ги бројачите пред да објавите

Правилата што никогаш не се совпаѓаат изгледаат исто како правилата што работат додека не ги изброите пакетите. Прочитајте ја табелата повторно со бајтни бројачи пред да се поврзе кој било клиент, потоа поврзете се од мрежа што не е LAN и прочитајте ја повторно. Двете читања се она што претпоставката ја претвора во факт. Објавете го пренасочувањето само откако второто ќе се помести.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Нула бројач на правилото за извор по вистинска врска значи дека совпаѓањето е погрешно, обично затоа што одредиштето или портата не се совпаѓаат со пакетот по преведувањето. Ако бројачот расте, но клиентот сѐ уште добива истек на време, повратниот пат е поправен и нешто друго го отфрла одговорот, па следно погледнете ја политиката за пренасочување од другата страна. Пристапот преку шнола од внатрешноста на LAN е одделен проблем и бара сопствено правило, не поширока верзија од ова.