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