ufw allow 443 не дапамог службе за VPN
Дазвол на ўваходныя злучэнні датычыцца хоста з міжсеткавым экранам, а не машыны за ім. Прачытайце блок UFW, затым напішыце правіла маршруту для службы, што перасылаецца.
Ping праходзіць ад кліента VPN, служба TCP не адказвае, а ufw allow 443/tcp не змяняе нічога. Калі праграма працуе на хосце за шлюзам, а не на самім шлюзе, гэты дазвол быў напісаны для няправільнага шляху трафіку. Пакет не адрасаваны міжсеткаваму экрану і не перадаецца лакальнаму працэсу, таму правілы ўваходу яго ніколі не бачаць. Выпраўленне — гэта правіла маршруту, накіраванае на перасылаемы паток, і доказ для яго ўжо ёсць у журнале.
Вызначце, ці мэта лакальная або перасылаемая
Чытайце пакет так, як яго бачыць ядро. Трафік, які дастаўляецца службе на шлюзе, — гэта лакальны ўваход. Трафік, які шлюз перасылае да іншага хоста, з'яўляецца перасылаемым, і UFW трымае асобныя наборы правіл для двух шляхоў. Адрозненне вызначаецца адрасам прызначэння і пошукам маршруту, а не тым, праз які інтэрфейс прыйшоў пакет.
Радок журнала з адным і тым жа інтэрфейсам у палях IN і OUT можа апісваць перасылаемы пакет, бо тунель, які носіць кліентаў уваходна і выходна праз адну прыладу, выглядае менавіта так. Адрас прызначэння вырашае пытанне хутчэй, чым назвы інтэрфейсаў. Двухразовае бачанне таго ж імя не даказвае лакальнай дастаўкі, а выдумванне інтэрфейса тунеля, якога разгортванне ніколі не стварала, таксама не дапамагае.
Прачытайце блок, перш чым дадаваць любое правіла
Аднавіце адну дазволеную спробу злучэння і запішыце яе крыніцу, прызначэнне, пратакол і порт прызначэння так, як іх зафіксаваў шлюз. Параўнайце гэтыя чатыры значэнні з запісам у журнале і з фактычным размяшчэннем службы. Папярэдні паспяховы ping даказвае толькі тое, што быў дазволены яго ўласны абмен, і міжсеткавы экран можа апрацоўваць TCP SYN да праграмы зусім інакш.
sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered
Першая каманда вяртае вердыкт разам з яго палямі, а другая паказвае, што ўжо загружана і ў якім парадку. Прачытайце абедзве, перш чым нешта рэдагаваць, бо папярэдняя забарона вышэй за ваша правіла тлумачыць той жа сімптом без адсутнага правіла.
Напішыце самае вузкае правіла маршруту, якое падыходзіць
У гэтым прыкладзе кліенты прыходзяць праз tun0 з 172.20.8.0/24, служба слухае 10.30.0.15 на порце 8443, а шлюз выходзіць праз ens5. Гэтыя значэнні абраны так, каб не выглядаць як стандарт воблачнага VPC 10.0.0.0/16 або хатняй сеткі 192.168.0.0/16, а 8443 трымае прыклад далей ад уласнага слухача 443 на шлюзе.
sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
Пробны запуск друкуе набор правіл, які атрымаецца, і гэта самы танны спосаб убачыць, ці трапіць ваша правіла перад існуючай забаронай або пасля яе. Зверце назвы інтэрфейсаў і ўнутраныя адрасы з разгортваннем, а не з прыкладам, і памятайце, што калі трансляцыя адраса прызначэння выконваецца першай, фільтр бачыць ужо перакладзены адрас.
Захавайце зваротны шлях з улікам стану
UFW адсочвае дазволеныя злучэнні, таму адказы на дазволены перасылаемы паток прымаюцца без яўнага зваротнага правіла. Даданне неабмежаванага правіла ў супрацьлеглым напрамку, каб усё запрацавала, пашырае палітыку значна далей за адну службу і не патрэбна для звычайнага абмену запыт-адказ. Трымайце зваротны шлях неяўным, а набор правіл — чытэльным.
Ужывайце правіла толькі пасля таго, як пробны запуск супаў з вашымі намерамі, потым пераканайцеся, што ўпарадкаваны спіс паказвае яго ў чаканым месцы. Захоўвайце слухача VPN і правілы кіравання як асобныя пытанні; змяненне іх — гэта іншае рашэнне, чым дазвол адной праграме. Занатуйце змяненне там жа, дзе запісана тапалогія, каб наступны інжынер не адкрываў яго зноў па здымку пакетаў.
sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered
Праверце, што UFW не можа забяспечыць за вас
Правільнае правіла ўсё яшчэ патрабуе перасылкі на ўзроўні ядра і маршруту, які дасягае службы. Пераканайцеся ў абодвух, перш чым другі раз вінаваціць міжсеткавы экран.
sysctl net.ipv4.ip_forward
ip route get 10.30.0.15
Затым паглядзіце за межы хоста. На воблачным інстансе палітыка UFW гасцявой сістэмы не замяняе групы бяспекі, ACL падсетак або ўласную канфігурацыю перасылкі правайдэра, таму лакальная блакіроўка — гэта доказ пра адзін узровень, а не доказ таго, што ўсе іншыя ўзроўні дазваляюць службу.
Скончыце тэстам новага злучэння з уключаным міжсеткавым экранам, з дазволенай крыніцы і з незвязанай. Адключэнне UFW прыбірае сімптом і знішчае доказы адной камандай, таму гэта павінна быць апошнім эксперыментам, а не першым.