UFW изхвърля DNS сървъра на VPN, щом тунелът се вдигне
Политиката за забрана по подразбиране в UFW покрива и интерфейса на тунела. Подредете трафика по посока, допуснете изпратения резолвер на tun0 и след това отворете външния път.
Имената спират да се резолвят в момента, в който VPN се свърже, докато ping към публичен адрес още отговаря, а статусът на защитната стена не показва нищо, което да изглежда грешно. В политиката не се е променило нищо; променило се е, че се появи нов интерфейс и забраната по подразбиране го покрива от първия пакет. UFW решава по посока и интерфейс, затова правило, написано за безжичната връзка, не казва нищо за трафика, който излиза от тунела. Поправката е шепа тесни правила, приложени в определен ред.
Симптомът се появява само след като тунелът е вдигнат
Политиката за забрана по подразбиране прави точно това, което ѝ е казано: всичко без съответстващо правило се отказва, на всеки съществуващ интерфейс. Тунелът не е съществувал, когато са писани правилата, затова никое от тях не може да го покрие, а забраната, която винаги е била там, сега важи за резолвирането на имена. Директният трафик към буквален адрес все още може да работи, когато го покрива по-широко разрешение, и затова ping към публичен резолвер успява, докато търсенето на име се проваля. Празнината е правило за интерфейс, който политиката никога не е виждала.
Това също обяснява защо отказът се обръща чисто: махнете тунела и имената отново се резолвят, защото заявката се връща към интерфейс, който има правила. Политика, която се проваля само при вдигнат тунел, не е проблем с DNS, а настройването на самия резолвер тук губи най-много време. Прочетете списъка с интерфейси, преди да четете конфигурацията на резолвера.
Три посоки, три различни набора от правила
Една сесия докосва правила в повече от една посока, а тунелът добавя втори интерфейс към почти всяка от тях. Подреждането на трафика първо по посока и интерфейс прави останалото механично, защото всеки ред по-долу изисква собствено правило на собственото си място. Примерите използват 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 |
Два реда често се бъркат, защото и двата споменават тунела. Правило за резолвера допуска трафика, който клиентът изпраща в тунела, докато правило за SSH допуска трафика, който сървърът получава от него; те живеят на различни машини и се провалят независимо. Редът, който най-често се забравя, е вторият, защото клиентът изобщо не може да установи тунела, докато трафикът му към публичния адрес на сървъра не бъде разрешен. Работете отгоре надолу и всеки отказ има една вероятна причина.
Изпратеният резолвер изисква собствено правило
Дали тунелът носи DNS зависи от това какво изпраща сървърът. Сървър, който изпраща опция за резолвер, инсталира частен адрес в конфигурацията на клиента и този адрес е маршрутизируем само през тунела. Ако сървърът не изпраща нищо, клиентът запазва резолвера, който вече е имал, и правилата по-долу няма какво да допускат. Проверете изпратеното състояние и текущия резултат от заявката, преди да пишете каквото и да е:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedИзходът от статуса назовава използвания резолвер и връзката, към която е обвързан, а търсенето на маршрут зад него показва кой интерфейс би пренесъл заявка към този адрес. Когато резолверът седи на друга връзка, проблемът е по-рано от защитната стена и никакво правило няма да помогне. Когато двете съвпадат за тунела, са нужни две правила, защото 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'Отворете външния път преди вътрешния
Клиентът трябва да достигне публичния адрес на сървъра, преди да съществува тунел, затова правилото за него седи на физическата връзка и трябва да е на място първо. Политика, която допуска резолвера, но забравя сървъра, оставя клиента напълно неспособен да изгради тунела и този симптом обикновено се приписва на 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'Редът има значение, докато тествате, защото първото правило е това, което изобщо позволява на тунела да се вдигне. Добавете го, свържете се и потвърдете, че тунелът е вдигнат, преди да добавите правилото за услугата, защото да направите и двете наведнъж означава, че отказът не ви казва коя половина е грешна. Заменете адреса от документацията по-горе с крайната точка, за която клиентът е конфигуриран.
Завършете клиентската страна, като се изключите нарочно. Забраната трябва все още да отказва трафика, който умишлено сте изключили, защото резолвер, който отговаря при вдигнат тунел, покрива само половината от политика, която отказва при съмнение.
Клиент, който се свързва, още не е допуснат
Сървърът има собствена посока, която да обмисли, а клиент, който завърши ръкостискането, все още не може да достигне нищо, което работи на сървъра, докато сървърът не го допусне. Правилото за публичния слушател позволява само съществуването на тунела; то не пуска трафика на тунела. На сървъра това са две правила плюс една проверка, че услугата наистина слуша:
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 съвпадат по-рано и все още могат да отхвърлят пакет, който списъкът изглежда позволява.