Бөлөк чыгуу: usb0'дагы VPN пулу, eth0'дагы шлюз трафиги

Кардарлар туташып, аутентификациядан өтөт, анан алардын трафиги туура эмес жогорку канал аркылуу чыгат, анткени түзмөктөгү жалгыз демейки маршрут шлюздун өзүнө таандык. Ошол демейки маршрутту алмаштыруу түзмөктүн өз жаңыртууларын жана башкаруу кирүүсүн бузат, ошондуктан тандоо «бардык трафиктен» тар болушу керек. Иштөөчү форма — кардар пулунун ички булак дарегине негизделген жана альтернативалуу WANга ээ экинчи маршруттоо таблицасын көрсөткөн саясат эрежеси. Андан ары текшерүү тизмеси эреженин өзү жөнүндө эмес, толуктук жана бузулуш учурундагы жүрүм-турум жөнүндө.

Булак дареги маршруттоо чечимине чейин сакталарын ырастаңыз

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

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

Реалдуу маанилерди жазуудан баштаңыз: пул префикси, аны ташыган туннель интерфейси, экинчи WANдын дареги жана кийинки секирүүсү, жана колдонууну көздөгөн таблицанын номери. Жаңы эрежелерди кошуудан мурун мурунку аракеттин эски эрежелерин тазалаңыз, анткени ар кандай артыкчылыктардагы кайталанган эрежелер кокустан окшогон бузулуштарды жаратат.

Толук тандалган таблицаны түзүңүз

Таблица — досу бар демейки маршрут эмес. Ага ар бир издөө анын ичинде чечилишиндей жетиштүү маршрут керек, анын ичинде WAN ички тармагынын туташкан маршруту, кийинки секирүү жеткиликтүү болушу үчүн. tun1'деги 10.77.0.0/24 пулу, кийинки секирүүсү 203.0.113.1 болгон 203.0.113.20/24 WAN дареги жана 600 таблицасы үчүн:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Эреже кандайдыр бир бардыгын кармаган эрежеден төмөн артыкчылыкта турат, ошондуктан дал келген кардарлар адегенде 600 таблицасына тийет, ал эми калганы негизги таблицага түшөт. ip-rule шилтемеси иреттелген издөө модели жана селектор синтаксиси толук сүрөттөйт.

Анан таблицада жок нерсе жөнүндө ойлонуңуз. Бир гана негизгиде маршруту бар бара турган жер, мисалы eth0 аркылуу жеткиликтүү башкаруу ички тармагы, 600 таблицасынан табылбайт жана анда демейки маршрут болгондон кийин негизгиге кайтпайт. Эгер бул жолдор маанилүү болсо, аларды тандалган таблицага ачык кошуңуз, бул VPN чыгуу таблицасы үчүн адатта туура жооп.

Угуучунун өз трафигин саясаттан тышкары кармаңыз

OpenVPN угуучусунун өз тышкы байланышы бар, ал кардар жеткен жогорку канал аркылуу ташылат. Бул трафик келген кайтуу жолун сактоого тийиш, ал эми сервердин жарыя дарегин же бүт туннель интерфейсин камтыган кенен эреже аны альтернативалуу таблицага тартып кетиши мүмкүн. Эрежени ички пул менен чектеңиз, башка эч нерсе менен эмес.

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

Тартип түзмөктөгү калган нерселерге карата да маанилүү. Docker көпүрөлөрү, экинчи VPN жана провайдердин образынан мурунтан бар эрежелер артыкчылыктарды кошот, ошондуктан 100 артыкчылыгы жалгыз деп болжолдобой, эрежелердин толук тизмесин окуңуз.

Кайра жөнөтүү жана котормо маршрут менен шайкеш болсун

Маршруттоо жогорку каналды тандайт; ал кайра жөнөтүүгө уруксат бербейт. Ядродо IPv4 кайра жөнөтүү күйгүзүлүшү керек, ал эми файрвол кардардан WANга багытты жана кайтуу трафигин кабыл алышы керек. Агымды таштаган FORWARD тизмеги бар туура таблица жок маршрут сыяктуу белги берет, ошондуктан экөө бир өтүүдө текшерилет.

Эгер экинчи WAN жеке пулду сизге кайра маршруттабаса, ошол чыгууда булакты которуңуз. Динамикалык дареги бар интерфейс үчүн пул жана интерфейс менен чектелген тар masquerade эрежеси адаттагы тандоо:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

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

Жолдор айырмаланганда туннелдин чыгымы да көңүл бурууну талап кылат. Кардарлар чоң TCP MSS боюнча макулдашса жана альтернативалуу WANдын MTUсы төмөн болсо же ичинде туннель болсо, чоң сегменттер токтоп, кичинелери иштейт. Кайра жөнөтүү жолунда MSSды кысуу муну мезгил-мезгили менен тоңуп калуунун ордуна болжолдонуучу жүрүм-турумга айландырат.

usb0 жоголгондо эмне болорун чечиңиз

Бош таблица — бузулуш учурунда жабылган абал эмес. Дал келген маршрут жоголсо, издөө кийинки эрежеге уланат, негизги таблицага жетет жана eth0 демейкисин алат. Экинчи WAN аркылуу чыгышы керек болгон трафик биринчиси аркылуу унчукпай чыгат, ал эми саясат менен маршрутталган жайылтууда бул адатта эң аз каалаган натыйжа.

Бул артка чегинүү кабыл алынгыс жерде 600 таблицасына ачык терминалдык маршрут кошуңуз, мисалы blackhole демейкиси, же интерфейс өчүк турганда пулду файрволдо таштаңыз. Экөөнүн кайсынысы болбосун — жазып коюуга боло турган чечим; унчукпастык андай эмес.

Туруктуулук — акыркы пункт. Эки байланышка тең ээ ким болбосун, ал тармак менеджериби, жөнөтүүчү скриптиби же байланыштын жашоо циклыбы, ар бир кайра туташууда көчүрмөлөрдү кошпой маршруттарды жана эрежени кайра түзүүгө тийиш. Чыныгы кардардан суроо жана шлюзден өзүнчө суроо менен текшериңиз, экөөндө тең байкалган чыгууну ырастаңыз, анан экинчи WANды сууруп, долбоорлогон эки натыйжанын кайсынысы чындыгында болорун караңыз. IPv6га өз таблицасы, эрежеси жана котормосу керек; жогорудагы IPv4 эрежеси ал жөнүндө эч нерсе айтпайт.