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 сұраныс шын мәнінде қайдан шықса, содан жауап береді.