UFW одбацује DNS сервер VPN-а чим се тунел подигне
Политика подразумеваног одбијања у UFW-у покрива и интерфејс тунела. Поређајте саобраћај по смеру, дозволите гурнути resolver на tun0 и затим отворите спољашњи пут.
Имена престају да се разрешавају у тренутку када се VPN повеже, док ping на јавну адресу још увек одговара, а статус заштитног зида не показује ништа што изгледа погрешно. У политици се ништа није променило; променило се то да се појавио нови интерфејс, а подразумевано одбијање га покрива од првог пакета. UFW одлучује по смеру и интерфејсу, зато правило написано за бежичну везу не говори ништа о саобраћају који излази из тунела. Поправка је шака уских правила примењених у одређеном редоследу.
Симптом се појављује само пошто се тунел подигне
Политика подразумеваног одбијања ради тачно оно што јој је речено: све без одговарајућег правила се одбија, на сваком интерфејсу који постоји. Тунел није постојао када су правила писана, па ниједно од њих не може да га ухвати, а одбијање које је одувек било ту сада важи за разрешавање имена. Директан саобраћај ка буквалној адреси још може да ради када га покрива шире одобрење, и зато ping на јавни resolver успева док тражње имена не успева. Празнина је правило за интерфејс који политика никада није видела.
То такође објашњава зашто се квар чисто преокрене: спустите тунел и имена се поново разрешавају, јер упит се враћа на интерфејс који има правила. Политика која не успева само док је тунел подигнут није 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 је намерно за административни порт, јер ограничава поновљене везе уместо да их прима без ограничења. Провера слушаоца раздваја затворен порт од одбаченог пакета, који са стране клијента изгледају исто. Ни нумерисана правила нису цела слика: before правила UFW-а и сваки ручно написан nftables ред поклапају се раније и још увек могу да одбију пакет који листа изгледа да дозвољава.