Барлық портты бағыттайтын ереже 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 сессиясын ашыңыз және мониторинг әлі де есеп беретінін растаңыз. Жарияланған қызмет басқару жазықтығы бұзылған кезде жұмыс істеуі мүмкін, сондықтан екі тексеру де бір өзгеріс терезесінде болуы керек. Ережелердің күтілген тәртіппен қайта қолданылғанын дәлелдеу үшін бір рет қайта жүктеңіз, содан кейін жариялауды алып тастап, алып тастаудың қосуды дәл қайталайтынын растаңыз. Іске қосу кезіндегі көп қосулар мен толық емес тазалау — уақытша сынақтың тұрақты ашықтыққа айналу жолы.