виртуальный шлюз iptables

Недавно я столкнулся с подобным симптомом (добавлены разрывы строк для удобства чтения):

# 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.

1
27.09.2021, 12:49
1 ответ

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 ).

0
29.09.2021, 05:52

Теги

Похожие вопросы