Апублікаваць службу 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, захоўваючы крыніцу кліента. Абмежаваная трансляцыя крыніцы замест гэтага хавае кліента за адрасам шлюза ў лакальнай сетцы.

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

Выбірайце па тым, што патрэбна службе. Палітыка для кожнага кліента і змястоўныя журналы патрабуюць маршрутызаванай формы; прылада, якой нельга даць маршрут, або служба, якая абавязкова мусіць бачыць адрас лакальнай сеткі, паказваюць на трансляваную форму. Не хапайцеся за глабальнае правіла masquerade, каб прымусіць працаваць адзін адказ. Яно хавае кожнага кліента ад кожнага прызначэння і ціха ламае палітыкі, якія залежаць ад адрасоў крыніцы.

Не правярайце з самога шлюза

Запыт, створаны на шлюзе да 10.62.0.1, выходзіць праз ланцуг OUTPUT, а не праз уваходны PREROUTING. Яго няўдача ці поспех нічога не кажуць пра правіла, скіраванае да кліента, і менавіта так людзі робяць выснову, што працоўнае правіла зламанае.

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

Запусціце сапраўдны запыт кліента і прачытайце абодва. Запіс conntrack паказвае, якая трансляцыя была ўжытая, а перахопы паказваюць, ці перасек запыт у лакальную сетку і ці вярнуўся адказ у бок тунеля. Выкарыстоўвайце новае злучэнне пасля змены правілаў, бо існуючы стан захоўвае ранейшае адлюстраванне і будзе далей падаць па-старому. Затым пацвердзіце ўсю размову: адрас прылады, дазвол перанакіравання і маршрут адказу апісваюць адзін і той жа паток.