Публикуване на LAN услуга на собствения адрес на VPN шлюза

Показването на LAN устройство на един от собствените тунелни адреси на шлюза отнема един ред NAT. Връзката все още се проваля, защото устройството, което отговаря, няма представа, че адресът на клиента е достъпен през този шлюз. Проследете пакета от клиента навътре, после проследете отговора обратно навън и липсващата половина ще стане очевидна.

Започнете от гледната точка на клиента

Клиентът в този пример се намира в пула на VPN 10.62.0.0/24 и се свързва с 10.62.0.1 на порт 8080. Този адрес принадлежи на самия шлюз, затова пакетът пристига в ядрото на шлюза, а не при друг партньор. Зад шлюза локалната мрежа е 172.21.4.0/24. Шлюзът държи 172.21.4.10, а устройството, което всъщност обслужва HTTP, е 172.21.4.40.

Адрес, който принадлежи на друг VPN партньор, не е взаимозаменяем с адреса на услугата на шлюза. Ако клиентът се свързва с адреса на партньор, никакво правило на шлюза не участва и цялото това разглеждане е за грешния случай.

Ограничете транслацията на дестинацията умишлено

Тясната версия показва един порт и пренаписва само дестинацията. Пакетът запазва протокола и източника си и точно това прави останалата част от пътя интересна.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Правило без критерии за протокол и порт е широката версия: то запазва който и да е порт, избран от клиента, като променя само адреса. Това е законно, когато трябва да се покаже целият хост, и грешно, когато е била целта една услуга. Прочетете правилото отново и потвърдете името на интерфейса. Правило DNAT на грешния интерфейс не съвпада с нищо, което дава същото изчакване като липсващо правило и прахосва час гледане към устройството.

Нека границата на пренасочване се съгласи

Транслацията променя заглавката, но не дава разрешение. При политика на отхвърляне по подразбиране пренасоченият поток се нуждае от собствено разрешение, а обратната посока — от правилото за установена връзка, което политиката ви вероятно вече има.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Безусловното разрешение за всеки DNAT поток е по-широко от този дизайн и ще позволи и съпоставяния, добавени по-късно от някой друг. Назовете дестинацията и порта, а останалото оставете затворено. Ако броячите на правилото за пренасочване остават нула, докато броячите на NAT растат, пакетът се отхвърля преди вашето правило. Четете реда на веригите, вместо да добавяте второ копие.

Устройството трябва някак да отговори

След транслацията устройството вижда източник в 10.62.0.0/24. Отговорът му отива към шлюза му по подразбиране, който е маршрутизаторът на локалната мрежа, а не VPN шлюзът, освен ако нещо не му каже друго. Две подредби поправят това и те не са еквивалентни. Маршрут на устройството или на маршрутизатора на локалната мрежа изпраща 10.62.0.0/24 към 172.21.4.10, запазвайки източника на клиента. Ограничена транслация на източника вместо това скрива клиента зад LAN адреса на шлюза.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Избирайте според това, което е нужно на услугата. Политика за всеки клиент и смислени журнали искат маршрутизираната форма; устройство, на което не може да се даде маршрут, или услуга, която просто трябва да вижда LAN адрес, сочат към транслатната форма. Не посягайте към глобално правило masquerade, за да проработи един отговор. То скрива всеки клиент от всяка дестинация и тихо чупи политиките, които зависят от адресите на източника.

Не тествайте от самия шлюз

Заявка, генерирана на шлюза към 10.62.0.1, излиза през веригата OUTPUT, а не през входящата PREROUTING. Нейният провал или успех не казва нищо за правилото, обърнато към клиента, и точно така хората стигат до извода, че работещо правило е счупено.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Пуснете истинска клиентска заявка и прочетете двете. Записът в conntrack показва приложената транслация, а прихващанията показват дали заявката е преминала към локалната мрежа и дали отговор се е върнал към тунела. Използвайте нова връзка след промяна на правилата, защото съществуващото състояние пази предишното съпоставяне и ще продължи да се проваля по стария начин. После потвърдете целия разговор: адресът на устройството, разрешението за пренасочване и маршрутът на отговора описват един и същ поток.