NAT артындагы OpenVPN кардары кантип интернет чыгымына айланат

Үч Linux хосту, бир долбоор: коомчулукка жеткиликтүү OpenVPN хабы, керектөөчүнүн ноутбугу жана ичке эч нерсе өткөрбөгөн кадимки үй маршрутизаторунун артындагы чыгуу машинасы. Чыгуу хабга өзү чалат. Андан кийин керектөөчүнүн интернет трафиги ноутбукта туннелге кирип, чыгуунун өз жогорку агымы аркылуу чыгат. Бул курулушта таң калыштуунун баары бир деталдан келип чыгат: байланышты чыгуу баштаган, ошондуктан ичке карай жол мурун эле бар жана аны түзүү үчүн порт өткөрүү керек эмес.

Төмөнкү баян конфигурация тартибин эмес, пакеттин жолун байкайт, анткени конфигурация кайсы компонент кандай чечим кабыл аларын билгенде гана мааниге ээ. Ар бир катмар так бир чечим кабыл алат, ал эми каталар эки катмар бир деп эсептелген жерде топтолот.

Эки транспорттук сессия, бир ички жол

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

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

Эки тышкы байланыш тең кардар тараптан сыртка чыккандыктан, чыгуунун маршрутизатору эч качан кирүү SYN көрбөйт жана эч качан багыттагы NAT эрежесин талап кылбайт. Ал орнотулган транспортту тирүү кармоо гана керек, муну ал каалаган узак байланыш үчүн мурун эле жасайт. Ачык интернетте эч нерсе адегенде чыгууга жетиши керек эмес, ошондуктан ал жогорку агымдагы динамикалык дарек көйгөй эмес. Маршрутизатор чыгуучу сессияга уруксат бериши керек, бирок бул браузер мурун эле колдонгон уруксат.

iroute сервердин ичинде чындыгында эмнени орнотот

Хаб — кайсы өнөктөштүн кайсы багытка ээ экенин чечкен жалгыз түзмөк, жана бул чечимди ядродо эмес, өзүнүн колдонуучу мейкиндигинин маршрут таблицасында кабыл алат. Чыгуу үчүн exit-node аталган client-config-dir жазуусу ал жерде демейки префиксти талап кыла алат:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

Ал сап сервер процессине "каалаган багыты бар ички пакеттер ушул кардардыкы" дейт. Ал хабдын операциялык системасына демейки маршрут кошпойт жана хабды интернет дарбазасына айландырбайт. OpenVPN 2.6 колдонмосу кардарга тиешелүү ички маршруттоо менен ядронун маршруттоосун өзүнчө механизмдер катары кармайт, жана дал ушул бөлүнүү хабдын демейки маршрутуна тийбестен долбоордун иштешинин себеби.

Керектөөчүгө күзгү сыяктуу нускама керек, push катары жеткирилет, ошондо анын өз трафиги жергиликтүү дарбазадан чыкпай туннелге кирет. Ички тармак топологиясында пул чыгуунун tun түзмөгүндөгү туташкан маршрут, ошондуктан кайтуу багыты кошумча push талап кылбайт; чыгуу албашы керек нерсе — төмөнкү багыттоо, ал өзүнүн жогорку агым трафигин колдонууга аракет кылган туннелге кайра жиберет. Аны керектөөчүгө гана жибериңиз жана CCD файлы тандалды деп ишенүүнүн ордуна кардардагы колдонулган маршруттарды окуңуз.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

Өткөрүүнү чыгуунун ядросу жасайт

Чыгуунун ичинде керектөөчүнүн пакети tun интерфейсине кандайдыр бир интернет хосттун дареги менен келет. Ядро маршрут таблицасын карап, эң жакшы дал келүү катары чыныгы жогорку агымды табат, анан эки көз карандысыз саясатты колдонот: бул пакетти такыр өткөрүүгө болобу жана ал ошол интерфейстен ошол булак дареги менен чыга алабы. Өткөрүү — sysctl, жана көп дистрибутивдерде демейки боюнча өчүк.

Ошондуктан чыгууга туруктуу күйгүзүлгөн IPv4 өткөрүү, керектөөчүнүн туннель булактарын жогорку агымга өткөргөн эреже жана tun аркылуу кайтуучу жооп жолу керек. Бүт хост үчүн өткөрүүнү күйгүзүү анын аркылуу маршрутталган башка нерселердин жүрүм-турумун да өзгөртөт, ошондуктан эреже баарын кабыл алуунун ордуна булактарды жана интерфейстерди аташы керек.

Кайтуу жолун булак котормосу сатып алат

Интернет хосттун 10.90.0.x дарегине маршруту жок, ошондуктан жооптор чыгууга жетпей эле ыргытылмак. Пакет жогорку агымдан чыгарда булакты кайра жазуу муну чечет, ал эми байланыштарды көзөмөлдөө кайтууда кайра жазууну тескери кайтарат.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

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

Хаб кайда талап кыла алат, кайда албайт

client-to-client жана салттуу колдонуучу мейкиндигинин маалымат жолу менен хаб ички пакеттерди сервер процессинин ичинде өнөктөштөрдүн ортосунда өткөрүп берет. Алар эч качан хабдын ядросунун FORWARD чынжырынан өтпөйт, ошондуктан ал жердеги ядро эрежеси өнөктөштөрдүн ортосундагы өтүүнү чектей албайт, канчалык кылдат жазылса да. Аткаруу сервердин өз саясатында жашоого тийиш: кимге туташууга уруксат, кайсы CCD файлын алат жана чыгуунун демейки ээлиги такыр берилеби.

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

Мүчөлүк — чыныгы көзөмөл. Өз маршруттарын конфигурациялай алган ар кандай кардар чыгууну колдонууга аракет кыла алат, ошондуктан кимдин туташа аларын же чыгуу кайсы өнөктөштөргө кызмат кыларын чектөө долбоордун бөлүгү, кийинки ой эмес.

Чыгуу жок болгондо коопсуз ишке жарамсыз болуу

Чыгууну өчүрүңүз, ички демейки ээлик анын сессиясы менен кошо жок болот. Болбошу керек нерсе — хаб үнсүз алмаштыруучу чыгууга айланышы: VPN пулунан хабдын жогорку агымына демейки маршрут жок жана хабда ошол эле трафикти кубаныч менен өткөрө турган кенен маскировка эрежеси жок. Бул ишке жарамсыздыкты атайын текшериңиз, анан калыбына келүүнү мурун ачылган бет менен эмес, жаңы агым менен текшериңиз.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Чыгуу кеткенден кийин да керектөөчүнүн трафиги интернетке жетсе, аны башка нерсе ташып жатат жана сиз көздөгөн чек жок. DNS жана IPv6 да өзүнчө чечим катары караңыз: IPv4 маршруту кошулган маскировка AAAA трафиги жөнүндө эч нерсе айтпайт, ал эми хаб түрткөн resolver суроо чындыгында кайдан чыкса, ошондон жооп берет.