VPN субтармагына портту багыттоодо SNAT колдонуу керекпи?

Портту маршрутизатордун өзүнүн 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 ичинен чач төөнөгү аркылуу кирүү өзүнчө маселе жана өз эрежесин талап кылат, бунун кененирээк версиясын эмес.