VPN жана веб үчүн бир жарыя хост: ролдорду кантип бөлүү керек

Бир машина үч муктаждыкты бир убакта канааттандыра алат: туннелдерди бүтүрүү, HTTPSке жооп берүү жана эки жеке LANдын ортосунда жөнөтүү. Бул акылга сыярлыкпы, ал кагазда чечсе боло турган үч нерсеге байланыштуу: жарыя дарек кимдики, ар бир порт жана протокол жуптары кимдики жана кайсы процесске пакеттерди жөнөтүүгө уруксат берилген. Ушулар туура болсо, жалпы хост эч нерсеси менен өзгөчөлөнбөйт. Туура эмес болсо, таза иштеп башталып, эч качан жооп бербеген кызматка дем алыш күнүн жумшайсыз.

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

Даректин ээсин порттордон мурун тандаңыз

Туннелдин акыркы чекити жана веб-сервер бир ядрону бөлүшө алат; бир даректи, портту жана протоколду бир убакта бөлүшүү — ийгиликсиз болгон нерсе. WireGuard адатта UDP 51820 колдонот, OpenVPN UDP 1194 же TCP 443 колдонот, ал эми веб-сервер TCP 443 колдонот. Оорута турган жуп — HTTPSтин жанындагы TCP 443 үстүндөгү OpenVPN, анткени экөө тең бир сокетти каалашат жана ядро аны биринчи байланганга берет. Тек алдында турган демультиплексор, мисалы sslh же TLSди түшүнгөн прокси, аларга бул портту бөлүшүүгө жол берет, жана ал иштебей калышы firewall көйгөйүнө так окшош компонентти кошот.

Бир нерсени өзгөртүүдөн мурун ээлерди караңыз: ss -lntup ар бир угуп жаткан сокеттин жергиликтүү дарегин, портун жана процессин басып чыгарат. Эки сап 0.0.0.0:443 көрсөтсө, анда экинчи кызмат эч качан байланган эмес, анын init скрипти канчалык кубанычтуу болбосун. Көпүрө да ээсин жылдырат. Качан eth0 көпүрөгө кошулат: br0, IP br0 дарегине өтөт жана eth0 деп атаган ар бир firewall эрежеси дал келбей калат, ошондуктан кызматтарды көпүрөгө байлап, ip -br addr аркылуу ырастаңыз.

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

Эки LANдын ортосунда маршруттаңыз же бир жагын NAT кылыңыз

Бири-бирин көрбөгөн эки LAN ар бири жарыя хостко чалып, ал кийин туннелдердин ортосунда жөнөтөт. Бул маршрутталган долбоорго үч нерсе керек: күйгүзүлгөн жөнөтүү, ар бир алыскы префикске маршрут жана транзитти өткөргөн жөнөтүү саясаты. sysctl -w net.ipv4.ip_forward=1 биринчисин камтыйт, ip route add 10.20.0.0/24 dev wg1 экинчисин, ал эми nftables сабы nft add rule inet filter forward iifname "wg0" oifname "wg1" accept үчүнчүсүн.

Баштапкы NAT кошууга оңой жана оңдоого кыйын. Маскировка клиенттин дарегин кайра жазат, ошондуктан алыскы тарап чыныгы хостту эмес, хабды көрөт, жана анын кирүү эрежелери менен журналдары атрибуция үчүн пайдасыз болуп калат. Эки тармак тең сиздики болсо, маршруттаңыз. Бир жагы кайтаруу маршрутун кошпогон үчүнчү тарапка таандык болсо, NAT — ушул аптада чыга турган вариант. Кандай болбосун дарек планын жазыңыз, анткени эки капталган /24тү эч бир конфигурация маршруттай албайт.

Ноутбук үчүн интернет чыгуучу жер катары иштөө ошол кутунун кирүүчү туннелдерди бүтүрүүсүнө тоскоол болбойт. Тек капталган даректер гана тоскоол болот, ошондуктан дарек планы маанилүү документ.

Эки роль токтоп турганда бөлүүнү текшериңиз

Пайдалуу тест — кемитүү: эки ролду токтотуп, үчүнчүсү дагы эле жооп берерин ырастаңыз. Туннель кызматы өчүк турганда веб-суроо бүтүшү керек, ал эми веб-сервер токтогондо туннель кол алышуусу бүтүшү керек. Экөө тең баары иштегенде гана иштесе, сизде кокустан келип чыккан көз карандылык бар, мисалы жалпы firewall таблицасы, адашкан маршрут же туура эмес дарекке көрсөткөн ат.

Үч буйрук бул тестти конкреттүү кылат. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ жергиликтүү угуучунун тышкы DNSсиз жооп берерин далилдейт, wg show клиентте кол алышуу бүткөнүн далилдейт, жана tcpdump -ni any port 51820 хабда маршруттоо маселесин ачкыч маселесинен ажыратат. Тартууда эч качан көрүнбөгөн кол алышуу хосттон мурун өлдү: провайдердин firewallы, туура эмес жарыя дарек же жолдогу NAT эрежеси.

Жөнөтүлүүчү LANдар үчүн кемитүүнү кайталаңыз. Бир теңтуш ажыратылганда хаб аркылуу ping ийгиликсиз болушу керек; кайра туташканда ping эрежеге тийбестен калыбына келиши керек. Туннелди кайра иштеткенден кийин гана калыбына келген ping жеткиликтүүлүккө эмес, саясатка көрсөтөт, жана бул башка оңдоо.

Ролдорду алып салганда эрежелер жыйнагын окулуучу бойдон кармаңыз. nft list ruleset чын эле керектүү ар бир багытка бир кабыл алуу эрежесин көрсөтүшү керек, ал эми баарын кабыл алган жөнөтүү чынжыры — бөлүү эмес, иштеп жаткан демо.

Тек IPv6 кирүү линиялары жана IPv4 кызматтары

Айрым кирүү линиялары тек IPv6 жеткиликтүүлүгүн берет, ал эми кызматтар дагы эле IPv4 аркылуу жарыяланышы керек. Туннелдин өзү дагы эле трафикти өткөргөн үй-бүлө аркылуу жүрөт, ал эми жарыяланган кызмат туннелдин ичиндеги даректе отурат. Бул кадимки божомолду тескери бурат жана мониторингди үнсүз бузат: IPv4 жолу үчүн жазылган firewall эрежеси же иштөө убактысын текшерүү эми эч нерсе ташыбаган интерфейсти байкайт.

Ар бир үй-бүлөнү өзүнчө текшериңиз curl -4 жана curl -6 аркылуу, анткени бир ийгиликтүү суроо сиз сынабаган жол жөнүндө эч нерсе айтпайт. Порттун ээлиги үй-бүлөлөрдүн ортосунда өзгөрбөйт, бирок угуучу өзгөрөт: ss -lntup IPv4 жана IPv6 сокеттерин өзүнчө саптарда тизет, жана 0.0.0.0:443 камтыбайт: [::]:443 ды, эгер процесс dual-stack сокет сурабаса.

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