Бардык портторду багыттаган эреже WireGuard угуучуңузду жутуп кетиши мүмкүн
Кенен багыттоо эрежеси шлюздин өзүнүн WireGuard жана SSH угуучуларын жутуп кетиши мүмкүн. Тар эрежелерди же өзүнчө жарыя даректи тандап, анан башкаруу жолун текшериңиз.
Жарыя шлюз мурунтан эле WireGuardды UDP 51820, SSHды 22 портунда жана интернеттен жеткиликтүү болушу керек болгон бир колдонмону иштетип жатат. Кызыктырган эреже ар бир портту теңдешке багыттап, иш бүттү деп эсептейт. WireGuard шлюзинде мындай эреже туннелдин өз ташуусун кармап алып, аны бүтүргөн машинадан сизди кулпулап коюшу мүмкүн. Жарыялоо — башкаруу тегиздигинин өзгөчөлүгү бар маршруттоо чечими, бир DNAT сабы эмес.
Жарыя кирүү же туннель кирүү: бирөөнү тандаңыз
Кызматты жарыялоо интернетке кирүүнүн жаңы чекитин түзөт. Бул теңдешке VPN мүчөлүгүн берүү менен бирдей эмес, анткени келүүчү туннелге эч качан кирбейт жана шлюз бэкенддин жарыя жүзүнө айланат. Ушул айырма эреженин аудиториясын жана анын сертификатын аныктайт.
Административдик интерфейстер бул орунга сейрек туура келет. Авторизацияланган VPN кардарлары жеткен админ баракчасы чабуул бетине туннелдин ичинде кармап, кирүү формасын туш келди скандоого чыгарбайт. Жарыя колдонмо четки чекиттерине дагы эле өзүнүн TLS сертификаты, аутентификация жана ылдамдыкты чектөө керек; шифрленген WireGuard кадамы келүүчүнүн шлюзге чейинки бөлүгүн коргобойт.
Эгер кызмат чын эле жарыя болушу керек болсо, хост атын, аны камтыган сертификатты жана ага жетиши керек болгон келүүчүлөрдүн диапазондорун жазып алыңыз. Ушул үч факт кийин эреженин формасын жана чыпкалоо саясатын аныктайт. Алардан тышкары нерселердин баары жарыя угуучуга көлөмдүн кеңейиши.
Бир порт кирет, бир бэкенд чыгат
Бир жарыя портту жана бир бэкенд кызматын колдонуңуз. Бул мисалда eth0 жарыя 198.51.100.20 дарегин алып жүрөт, шлюздин туннель дареги 10.200.0.1, ал эми теңдеш колдонмону 10.200.0.7де иштетет. Жарыя TCP 9443 теңдештин TCP 8443 портуна салыштырылат:
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1SNAT эрежеси которулган бэкендге жана баштапкы жарыя багытына дал келет, ошондуктан ошол эле бэкенд кызматына башка туташуу бул салыштыруудан тышкары калат. Ал ошондой эле келүүчүнүн дарегин теңдештен жашырат жана бул булакты сактаган маршруттук кайтууну өзүнчө долбоор кылган алмашуу. iptables кеңейтүүлөрүнүн маалыматтыгы эки максатты тең жана алардын дал келүү параметрлерин сүрөттөйт.
Багыттоо дагы эле күйгүзүлүшү керек жана чыпкалоо тизмегине которулган багыт менен портко, ошондой эле орнотулган жоопторго уруксат керек. FORWARD тизмеги DNATтан кийин которулган багытты көрөт, ошондуктан жарыя дарекке каршы жазылган эреже багытталган пакетке дал келбейт. Уруксатты бэкенд кортежине каршы жазыңыз, жарыяга каршы эмес.
Теңдеш кызмат туташуусун шлюздин туннель дарегинен кабыл алып, жоопту туннель аркылуу кайтарышы керек. Анын AllowedIPs иш жүзүндө алган булакка уруксат бериши керек, ал эми булакты которууда бул шлюздин туннель дареги, жана ар бир теңдеште кенен 0.0.0.0/0 жазуусу бул долбоор үчүн милдеттүү эмес. Кайтуу трафигин тизмесинде ошол дарек жок теңдеш же келүүчүнүн өз дарегин берген булакты сактаган долбоор токтотот, ошондуктан эрежеңиздегини эмес, теңдеш чындап көргөн булакты текшериңиз.
Шлюздин өз угуучуларын эрежеден тышкары кармаңыз
Багытты которуу машина пакетти жергиликтүү деп чечээрден мурун болот, ошондуктан UDP 51820 бардык теңдеш туташууларын кармап турган процесс эмес, теңдешке барып калышы мүмкүн. Эреже ийгиликтүү жүктөлөт жана туннель өлөт, бул теңдеш тараптан окууга кыйын бузулуу.
SSH, мониторинг агенттери жана шлюзде жайгашкан башка кандай гана кызмат болбосун ушундай таасирге ээ. Баарын багыттаган эреже башкаруу тегиздигин жарыяланган колдонмодон ажыратпайт жана өзгөртүүдөн кийинки биринчи кайра жүктөө кулпулоонун айкын болгон учуру. Баарын камтыган эреже өзү үнсүз кабыл алган кызмат жөнүндө эскертпейт. Сиз муну кийинки туташуу ишке ашпай калганда билесиз.
Эгер кенен багыттоо чын эле керек болсо, башкаруу портторун баарын камтыган эрежеге чейин калтырыңыз же жарыялоо үчүн өзүнчө жарыя даректи колдонуңуз. Экинчи вариант тазараак, анткени башкаруу дареги өз саясатын сактайт, бирок провайдер ошол даректи бериши керек; DNS жазуусун кошуу аны бөлүп бербейт.
Кенен TCP жана UDP багыттоо да бардык протоколдор эмес. ICMP, IPv6, жолдун MTU кайтарымы жана VPNдин сырткы ташуусу өз саясатын талап кылат, ал эми TCP менен UDPну камтыган эреже бул учурларды демейки тизмекке калтырат.
Эреже жазганга чейин моделди тандаңыз
Төрт форма шлюз жарыялоолорунун көбүн камтыйт, ал эми тандоо канча кызмат жүргүзүп жатканыңызга жана башкаруу тегиздигинин канча тобокелдигин көтөрө аларыңызга байланыштуу. Төмөнкү таблица аларды эң тардан эң кененге чейин иреттейт.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
Тар моделден баштаңыз, кийин кызмат көбөйөт деп күтсөңүз да. Аны текшерүү эң оңой, жана тар эрежелердин топтомун текшерилген баарын камтыган эрежеге айландыруу кенен эреженин кайсы угуучуну кармап алганын табуудан жөнөкөй. Кайсы моделди тандасаңыз да, эрежелерди файрволдун ээсинде кармаңыз. iptables саптарын ошол эле тизмектерди башкарган UFW же nftables конфигурациясынын жанында колдонуу жүктөө тартибине жараша өзгөрүүчү саясатты жаратат.
Жарыялоону да, башкаруу жолун да далилдеңиз
Авторизацияланган тышкы кардардан бекитилген хост аты жана ага жарактуу сертификат менен сынаңыз. Кайсы бэкенд жооп бергенин ырастап, анан байланышы жок жарыя порттордун дагы эле тыюу салынганын текшериңиз. Өчүрүлгөн сертификат текшерүү — ийгиликтүү HTTPS сынагы эмес, ал эми туура эмес бэкендге жеткен туташуу ишке ашпагандан жаман.
Андан кийин шлюздин өзүн текшериңиз: WireGuard теңдешин туташтырыңыз, SSH сессиясын ачыңыз жана мониторинг дагы эле отчет берип жатканын ырастаңыз. Жарыяланган кызмат башкаруу тегиздиги бузулганда иштеши мүмкүн, ошондуктан эки текшерүү тең бир өзгөртүү терезесинде болушу керек. Эрежелер күтүлгөн тартипте кайра колдонуларын далилдөө үчүн бир жолу кайра жүктөңүз, анан жарыялоону алып салып, алып салуу кошууга чындап дал келерин ырастаңыз. Ишке кирүүдө көп кошуулар жана толук эмес тазалоо — убактылуу сынактын туруктуу ачыктыкка айланыш жолу.