WireGuard аркылуу бир колдонмо: байлоо — маршруттоо эмес

Бул параметр ар бир колдонмо үчүн которгуч сыяктуу көрүнөт, ошондуктан адамдар клиентти WireGuard интерфейсине байлап, туннелди ушул клиент гана колдонот деп күтүшөт. Байлоо чындыгында баштапкы даректи тандайт. Андан кийин ядро бара турган жерге маршрут издейт, кадимки демейки маршрутту табат жана пакетти туннелдин дарегин кошуп физикалык звенодон жөнөтөт. Ниетти ошол баштапкы дарек үчүн тандалган маршрут гана аткарат.

Механизмдин эки жарымы бар: туннелдин трафиги гана колдонушу керек болгон маршруттоо таблицасы жана дал келген баштапкы даректи ал жакка жөнөтүүчү эреже.

Байлоо баштапкы даректи коёт, андан ашык эмес

Linux чыгуучу интерфейсти маршруттоо таблицасында бара турган жерди издей отуруп тандайт, бул издоөнү саясат эрежелери башка жакка буруу мүмкүнчүлүгүн алгандан кийин болот. Эрежелер баштапкы дарек, файрвол белгиси, кирүүчү интерфейс, UID же ал тургай порт боюнча тандай алышат; ар бири бүт трафик эмес, ушул трафик деп айтуунун башка жолу. VPN клиентинин конфигурациясы туннелдин маршруттары бар таблицаны тандайт; эреже кайсы трафикке ага кайрылууга уруксат экенин тандайт. Жалгыз байлоо экөөнү тең бербейт.

Ошондуктан бул ийгиликсиздик ушунчалык таң калыштуу көрүнөт. Колдонмо туннелдин дарегин сөзсүз колдонуп жатат, туннел сөзсүз иштеп жатат, ал эми трафик сөзсүз туура эмес интерфейстен чыгып жатат. Ар бир ырастоо чын, жана алар чогуу даректи маршрутка эч нерсе байлабаган системаны сүрөттөйт.

Туннелге өзүнүн таблицасын бериңиз

wg-quick маршруттарды профиль айткан жерге орнотот. [Interface] астына Table = 40 кошуу аларды негизги таблицанын ордуна 40 таблицага жылдырат. Интерфейсти көтөрүп, алардын жеткенин тастыктаңыз: ip -4 route ls table 40 туннелдин маршруттарын көрсөтүшү керек, ал эми ip -4 route get 10.66.127.142 ядро азыр алардын бирин кантип чечип жатканын көрсөтөт. Маршруттар өз таблицасында болгондо негизги таблица калган баары үчүн иштей берет.

IPv6 үчүн да ушундай кылыңыз, кең префиксти дал келтирүүнүн ордуна. ip -6 rule add from fd00::2/128 lookup 40 бир даректи бекитет; fc00::/8 хосттогу башка интерфейстер менен кагылышып, ойлогондон көбүрөөк дал келген эреже жаратышы мүмкүн.

Баштапкы дарек эрежесин кошуп, эсептегичтерди караңыз

Андан кийин эки жарымды туташтырыңыз: ip -4 rule add from 10.66.127.142/32 lookup 40, ошол эле даректи WireGuard интерфейсине тиркеп. Эки эрежени тең PostUp ичине салыңыз, кайра туташуу аларды калыбына келтирсин. Параметр менен эмес, чыныгы суроо менен текшериңиз: ip route get 1.1.1.1 from 10.66.127.142 туннелдин түзмөгүн аташы керек, ал эми curl --interface wg0 ifconfig.me үй дарегинин ордуна туннелдин дарегин билдириши керек.

Дагы ийгиликсиз болсо, ip -s rule окуңуз. Бар болгону менен эч качан дал келбеген эреже нөлдүк эсептегичтерди көрсөтөт жана бул туура эмес эрежени эреженин таптакыр жоктугунан ажыратат. Ушул бир буйрук колдонмо өзүнүн интерфейс параметрин этибарга албадыбы деген божомолду көп үнөмдөйт.

Тескери учур: SSHты туннелден сырткары кармаңыз

Карама-каршы маселе да ошончолук кеңири таралган: wg-quick демейки маршрутка ээ жана серверге SSH сессиясы ортосунда үзүлөт. Анын эрежелери төмөн артыкчылык номеринде турат, ошондуктан өзгөчөлүк алардан мурун бааланышы керек. ip rule add dport 22 ipproto tcp table main priority 123 муну жаңы iproute2де жасайт; селектор жеткиликсиз жерде агымды nftablesте белгилеп, анын ордуна белгини дал келтириңиз.

Жооп жолун да текшериңиз. Орнотулуп, анан үнсүз калган SSH сессиясында адатта асимметриялык маршруттоо болот: бир багыт туннелден, экинчиси физикалык интерфейстен чыгат. Сервердин дареги үчүн ip route get жооп кайсы жакка кетерин айтат.

Таблица номерин, баштапкы дарек эрежесин жана өзгөчөлүктү профилдин өзүнө жазыңыз. Үчөө тең бир долбоорго таандык жана чогуу оңдолот.