Недавно я столкнулся с подобным симптомом (добавлены разрывы строк для удобства чтения):
# pkg info
pkg: Warning: Major OS version upgrade detected. \
Running "pkg-static install -f pkg" recommended
pkg: warning: database version 34 is newer than libpkg(3) version 33, \
but still compatible
pkg: sqlite error while executing INSERT OR ROLLBACK INTO pkg_search(id, name, origin) \
VALUES (?1, ?2 || '-' || ?3, ?4); in file pkgdb.c:1544: \
no such table: pkg_search
Я сосредоточился на этой части сообщения об ошибке:
no such table: pkg_search
и в моем конкретном случае я смог решить свою проблему, выполнив:
# cp -p /var/db/pkg/local.sqlite /var/db/pkg/local.sqlite.safety
# sqlite3 /var/db/pkg/local.sqlite
SQLite version 3.28.0 2019-04-16 19:49:53
Enter ".help" for usage hints.
sqlite> CREATE VIRTUAL TABLE pkg_search USING fts4(id, name, origin);
sqlite>.quit
Этот конкретный SQL-запрос упоминается в этой ветке от января 2017 года.
После этого заклинания SQL pkg
снова заработал, и я смог обновить до последней версии pkg
, а затем обновить или переустановить остальные пакеты. Это была миграция с 10.x на 12.x, поэтому после обновления pkg
я сделал pkg upgrade -f
для всего, и больше не было предупреждений или sqlite3
ошибок :
.
# pkg -N; pkg info; pkg upgrade
pkg: 15 packages installed
apache24-2.4.41 Version 2.4.x of Apache web server
apr-1.7.0.1.6.1 Apache Portability Library
bash-5.0.7 GNU Project's Bourne Again SHell
db5-5.3.28_7 Oracle Berkeley DB, revision 5.3
expat-2.2.6_1 XML 1.0 parser written in C
gdbm-1.18.1_1 GNU database manager
gettext-runtime-0.20.1 GNU gettext runtime libraries and programs
indexinfo-0.3.1 Utility to regenerate the GNU info page index
libnghttp2-1.39.2 HTTP/2.0 C Library
libxml2-2.9.9 XML parser library for GNOME
linux_base-f10-10_10 Base set of packages needed in Linux mode for i386/amd64 (Linux Fedora 10)
pcre-8.43_2 Perl Compatible Regular Expressions library
perl5-5.30.0 Practical Extraction and Report Language
pkg-1.11.1 Package manager
readline-8.0.0 Library for editing command lines as they are typed
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
Netfilter и NAT здесь не задействованы, все дело в маршрутизации.
Поскольку правило политики сначала проходит через vpntable , и эта таблица маршрутизации всегда соответствует для предоставления ответа на поиск маршрута из-за маршрута по умолчанию, основная таблица маршрутизации больше не используется. когда используется собственный 172.16.1.1 шлюза. Так что больше нечего говорить использовать lan0 .
Таким образом, в то время как первоначальный выбор маршрута будет использовать lan0:
$ ip route get to 172.16.1.2
172.16.1.2 dev lan0 src 172.16.1.1 uid 1000
cache
после выбора этого маршрута будет установлен адрес 172.16.1.1 часть 172.16.1.0/24 и, таким образом, переключится на использование vpn0:
$ ip route get from 172.16.1.1 to 172.16.1.2
172.16.1.2 from 172.16.1.1 via 10.20.1.1 dev vpn0 table vpntable uid 1000
cache
Исправление заключается в добавлении исключения, чтобы оставаться на lan0 в этом случае.
Есть несколько способов сделать это, все должны решить проблему, обычно первым или последним (используются самые простые ):
указать маршрут LAN в таблице маршрутизации VPN
ip route add 172.16.1.0/24 dev lan0 table vpntable
или сначала разрешите локальную сеть для локального трафика (специальный iif lo
означает здесь локальный инициированный трафик , на самом деле он не включает интерфейс lo )с правило маршрутизации, вызывающее основную таблицу маршрутизации. Добавляется после того, как имеет более низкий приоритет и оценивается перед вызовом таблицы маршрутизации vpntable :
ip rule add iif lo to 172.16.1.0/24 lookup main
или как вариант предыдущего пункта :перейти через правило VPN, прямо к правилу, вызывающему основную таблицу маршрутизации:
ip rule add iif lo to 172.16.1.0/24 goto 32766
или указать интерфейс вместо адреса в первоначальном правиле маршрутизации (, который необходимо удалить):
ip rule delete from 172.16.1.0/24 lookup vpntable
ip rule add iif lan0 lookup vpntable
Таким образом, он не сработает для локального адреса, поскольку он не получен от lan0 .
В отличие от первых методов, последний даже не позволяет использовать VPN по умолчанию на шлюзе при привязке к источнику 172.16.1.1 (, который затем все равно будет подвергаться NAT правилу MASQUERADE ).