UFW нь туннель босмогц VPN-ийн DNS серверийг хаядаг
UFW-ийн анхдагч хоригийн бодлого туннелийн интерфейсийг ч хамарна. Урсгалыг чиглэлээр нь эрэмбэлж, tun0 дээр түлхсэн resolver-д зөвшөөрөл өгөөд дараа нь гадаад замыг нээ.
VPN холбогдох мөчид нэрс шийдэгдэхээ болих бөгөөд нийтийн хаяг руу ping хариу үйлдэл үзүүлсээр байх ба галт ханын төлөв буруу харагдах зүйл харуулахгүй байна. Бодлогод юу ч өөрчлөгдөөгүй; өөрчлөгдсөн нь шинэ интерфейс гарч ирсэн бөгөөд анхдагч хориг үүнийг эхний пакетаас эхлэн хамардаг. UFW чиглэл ба интерфейсээр шийддэг тул утасгүй холбоонд зориулж бичсэн дүрэм туннелиас гарч буй урсгалын талаар юу ч хэлэхгүй. Засвар нь тодорхой дарааллаар хэрэглэсэн хэдэн нарийн дүрэм юм.
Шинж тэмдэг туннель боссны дараа л илэрдэг
Анхдагч хоригийн бодлого хэлсэнчлэн яг хийдэг: тохирох дүрэмгүй бүхэн оршин буй бүх интерфейс дээр татгалзагдана. Дүрмийг бичих үед туннель байгаагүй тул тэдгээрийн аль нь ч түүнийг барьж чадахгүй, байсан хориг нь одоо нэр шийдвэрлэхэд хамаарна. Шууд хаяг руу хийх шууд урсгал илүү өргөн зөвшөөрөл хамарвал ажиллах боломжтой, иймээс нийтийн resolver руу ping амжилттай болж, харин нэр хайх нь бүтэлгүйтдэг. Цоорхой нь бодлого хэзээ ч хараагүй интерфейст зориулсан дүрэм юм.
Энэ нь бүтэлгүйтэл яагаад цэвэр эргэдэггүйг ч тайлбарладаг: туннелийг буулгахад нэрс дахин шийдэгдэнэ, учир нь асуулга дүрэмтэй интерфейс рүү буцна. Зөвхөн туннель боссон үед бүтэлгүйтдэг бодлого нь DNS асуудал биш бөгөөд resolver-ийг өөрөө тохируулах нь энд хамгийн их цаг үрдэг. resolver-ийн тохиргоог уншихаас өмнө интерфейсийн жагсаалтыг уншина уу.
Гурван чиглэл, гурван өөр дүрмийн багц
Нэг сесс дүрмийг нэгээс олон чиглэлд хүргэдэг бөгөөд туннель бараг бүгдэд нь хоёр дахь интерфейс нэмдэг. Урсгалыг эхлээд чиглэл, интерфейсээр эрэмбэлбэл бусад нь механик болно, учир нь доорх мөр бүр өөрийн газарт өөрийн дүрэм шаарддаг. Жишээнүүд tun0 болон 10.8.0.0/24 санг ашигладаг тул нэрс, хүрээг клиентийн өөрийн гаралтаас авсан зүйлээр соль.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
Хоёр мөр ихэвчлэн андуурдаг, учир нь хоёулаа туннелийг дурддаг. resolver-ийн дүрэм клиент туннель рүү илгээх урсгалыг зөвшөөрдөг бол SSH-ийн дүрэм сервер тэндээс хүлээн авах урсгалыг зөвшөөрдөг; тэд өөр машинд амьдардаг ба бие даан бүтэлгүйтдэг. Хамгийн их мартагддаг мөр нь хоёр дахь нь, учир нь клиент серверийн нийтийн хаяг руу урсгалыг зөвшөөрөх хүртэл туннелийг огт барьж чадахгүй. Дээрээс доош ажиллаж, бүтэлгүйтэл бүр нэг боломжит шалтгаантай.
Түлхсэн resolver өөрийн дүрэм шаарддаг
Туннель DNS зөөх эсэх нь сервер юу илгээхээс хамаарна. resolver-ийн сонголтыг түлхдэг сервер клиентийн тохиргоонд хувийн хаяг суулгадаг бөгөөд тэр хаяг зөвхөн туннелээр маршрутлагдана. Сервер юу ч түлхэхгүй бол клиент урьд байсан resolver-ээ хадгалж, доорх дүрмүүдэд зөвшөөрөх зүйл байхгүй. Ямар нэгэн зүйл бичихээс өмнө түлхсэн төлөв болон одоогийн асуулгын үр дүнг шалга:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedТөлөвийн гаралт ашиглагдаж буй resolver болон түүний холбогдсон холбоосыг нэрлэх бөгөөд түүний ард байгаа маршрутын хайлт тэр хаяг руу асуулгыг аль интерфейс зөөхийг харуулна. resolver өөр холбоос дээр суусан бол асуудал галт ханаас өмнө байгаа бөгөөд ямар ч дүрэм туслахгүй. Хоёулаа туннелийн талаар санал нийлбэл хоёр дүрэм хэрэгтэй, учир нь ихэнх асуулгыг UDP зөөдөг ба хариулт тасарвал TCP ажлыг авдаг. Хоёр утгыг бичиж ав, учир нь дүрмүүд яг тэднийг нэрлэнэ:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'Дотоод замаас өмнө гадаад замыг нээ
Клиент туннель үүсэхээс өмнө серверийн нийтийн хаягт хүрэх ёстой тул түүнд зориулсан дүрэм физик холбоос дээр сууж, эхлээд байрандаа байх ёстой. resolver-ийг зөвшөөрөөд серверийг мартсан бодлого клиентийг туннелийг огт барьж чадахгүй байдалд орхидог бөгөөд энэ шинж тэмдгийг ихэвчлэн kill switch-д тохдог. Дараа нь туннелээр үнэхээр хүссэн үйлчилгээнүүдэд зөвшөөрөл өг, нэг удаад нэг нарийн дүрэм, интерфейсийг бүхэлд нь нээхийн оронд. Нарийн дүрмүүд нь хориг байрандаа үлдэх боломжийн шалтгаан юм.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'Туршилтын үед дараалал чухал, учир нь туннелийг огт босгох боломж олгодог нь эхний дүрэм. Үүнийг нэмээд холбогдож, үйлчилгээний дүрмийг нэмэхээс өмнө туннель боссныг баталгаажуул, учир нь хоёуланг нь зэрэг хийвэл бүтэлгүйтэл аль хагас нь буруу гэдгийг юу ч хэлэхгүй. Дээрх баримт бичгийн хаягийг клиентийн ашиглахаар тохируулсан төгсгөлийн цэгээр соль.
Клиентийн талыг санаатайгаар салгаж дуусга. Хориг нь санаатайгаар хасагдсан урсгалыг одоо ч татгалзах ёстой, учир нь туннель боссон үед хариу өгдөг resolver эргэлзвэл татгалздаг бодлогын зөвхөн хагасыг хамардаг.
Холбогдсон клиент хараахан хүлээн авагдаагүй
Сервер өөрийн чиглэлийг харгалзах шаардлагатай бөгөөд гар барилтыг дуусгасан клиент сервер түүнийг хүлээн авах хүртэл сервер дээр ажиллаж буй юунд ч хүрч чадахгүй. Нийтийн сонсогчийн дүрэм зөвхөн туннель байхыг зөвшөөрдөг; туннелийн урсгалыг дотогш оруулдаггүй. Сервер дээр энэ нь хоёр дүрэм ба үйлчилгээ үнэхээр сонсож байгаа эсэхийг шалгах нэг шалгалт:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'Дүрэм дэх сан нь серверийн хуваарилдаг хүрээтэй тэнцүү байх ёстой бөгөөд туннелийн дугаар серверийн үүсгэсэнтэй тохирох ёстой, учир нь өөр интерфейсийн дүрэм дүрэмгүйгээс ялгагдахгүй. limit захиргааны портад зориуд хэрэглэгддэг, учир нь давтагдсан холболтыг хязгааргүй хүлээн авахын оронд хязгаарладаг. Сонсогчийн шалгалт хаалттай портыг хаясан пакетаас ялгадаг бөгөөд тэд клиентийн талаас ижил харагддаг. Дугаарласан дүрмүүд ч бүрэн зураг биш: UFW-ийн before дүрмүүд болон гараар бичсэн аливаа nftables мөр эрт тохирч, жагсаалт зөвшөөрч байгаа мэт харагдах пакетыг ч хаяж болно.