Објавете LAN услуга на сопствената адреса на VPN портата

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

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

Клиентот во овој пример се наоѓа во VPN базенот 10.62.0.0/24 и се поврзува со 10.62.0.1 на порта 8080. Таа адреса ѝ припаѓа на самата порта, па пакетот пристигнува во јадрото на портата, а не кај друг партнер. Зад портата, LAN е 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. Неговиот одговор оди кон неговата стандардна порта, која е LAN рутерот, а не VPN портата, освен ако нешто не му каже поинаку. Два распоредувања го поправаат тоа и тие не се еквивалентни. Рута на уредот или на LAN рутерот праќа 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 го покажува применетиот превод, а снимките покажуваат дали барањето преминало во LAN и дали се вратил одговор кон тунелот. По промена на правилата користете нова врска, бидејќи постојната состојба го задржува претходното мапирање и ќе продолжува да паѓа на стариот начин. Потоа потврдете го целиот разговор: адресата на уредот, дозволата за пренасочување и рутата на одговорот ја опишуваат истата тек.