EC2де strongSwan: VPC жумуш жүгүн багыттасын

Шлюзден иштеген туннель шлюзду гана далилдейт. Жумуш жүгүнүн ички тармагын багыттаңыз, конокто өткөрүүнү күйгүзүңүз, селекторлорду кеңейтиңиз, анан андан текшериңиз.

Туннель иштеп турат, шлюз үлгүсү алыскы тармакка ping жөнөтө алат, ал эми жанындагы колдонмо үлгүсү эч жерге жетпейт. Эч нерсе бузулган эмес. Ийгиликтүү тест VPN хостунда башталган жана ал ошол хост ошол эле IPsec мамилеси аркылуу башка булак дарегин алып өтө алабы, деп эч качан сураган эмес. Бул колдонмо ошол боштукту төрт кадамда жабат, ар бир ийгиликсиздикти көрүнүктүү кармаган тартипте.

Адегенде төрт даректи жазып алыңыз

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

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Мисал бекитилген, иштеген саясатка негизделген IPsec байланышын жана булакты сактаган агымды болжолдойт. Бул бир дайындалган даректи карызга алган NAT'туу алыскы кирүү кардары эмес жана бул айырма селекторлорду өзгөртүү керекпи же жокпу аныктайт.

1-кадам: жумуш жүгүнүн ички тармагына маршрут бериңиз

Жумуш жүгүнүн ички тармагы менен чындыгында байланышкан маршруттоо таблицасына алыскы префикс үчүн шлюздун тармактык интерфейсин көрсөткөн жол керек. Үлгүнүн ичинде орнотулган конок маршруту ошол AWS маршруттоо таблицасында жазуу эмес жана эч бир strongSwan конфигурациясы аны түзбөйт.

AWSтин түзмөк аркылуу маршруттоо боюнча колдонмосу тармактык интерфейс объектилерин жана өткөрүп берүүчү үлгүнүн булак/багыт текшерүү талабын сүрөттөйт. Бул текшерүү өзгөрүүсүн шлюз ролу менен чектеп, кадимки колдонмо үлгүлөрүн тынч калтырыңыз.

Бир бекитилген тармакка орун бошотуу үчүн VPCнин жергиликтүү маршрутун же бардык жазууну алмаштырбаңыз. Эч ким колдонбогон маршруттоо таблицасы үчүн консолдук бет көрсөткөндү эмес, эмне байланышканын жана активдүү экенин текшериңиз. Окшош көрүнгөн эки таблицанын байланыштары ар башка болушу мүмкүн. Маанилүүсү — жумуш жүгүнүн ички тармагы туташкан таблица.

2-кадам: конокто өткөрүүнү күйгүзүңүз

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

Коопсуздук топтору — бул кадам адатта токтоп калган жер. Ортоңку түзмөк үлгүлөрдүн ортосундагы түз байланыштын коопсуздук тобуна шилтеме жасоо жүрүм-турумун мурастабайт, ошондуктан башкарылуучу Client VPN мисалынан көчүрүлгөн эреже эч качан дал келбеши мүмкүн. Чыныгы жолдо коопсуздук тобун жана ички тармактын ACLин эки багытта тең текшериңиз.

3-кадам: селекторлорду чыныгы булактарга кеңейтиңиз

AWS тарапта 10.60.1.10/32 гана камтыган саясат 10.60.2.20 камтыбастан шлюзден башталган ийгиликти түшүндүрөт. Алыскы багытка карай маршрут трафик селекторун кеңейтпейт жана бул ошол таң калуунун экинчи жарымы.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Эгер макулдашылган долбоор бүт VPCни коргосо, эки тарап тең 10.60.0.0/16 жана 10.90.0.0/24 даректерин кабыл алышы керек. Эгер ал бир жумуш жүгүн коргосо, ошол тар префиксти атайылап колдонуңуз. Кандай болбосун, орнотулган CHILD-SA саясатын текшериңиз, анткени сиз оңдогон конфигурация менен аны башкача тарыткан тарап бирдей келишим эмес.

Алыскы жер сакталган VPC булактары үчүн жоопторду да көзделген IPsec шлюзу аркылуу артка багытташы керек. Башка булак-NAT эрежелери бар жерде корголгон трафик үчүн колдоого алынган NAT өзгөчөлүгүн сактаңыз; бекитилбеген жумуш жүгүн уруксат берилген хост дарегине айландыруу — башка инсандык келишим, сиз каалаган кирүүгө кыска жол эмес.

4-кадам: текшериңиз, керек болсо артка кайтарыңыз

Жумуш жүгүнүн өзүнөн жаңы уруксат берилген колдонмо операциясы менен сынаңыз, анан чыгарылышы керек болгон багыт менен кайталаңыз. Алыскы кызмат көргөн булак дарегин жана ал колдонгон кайтуу жолун жазып алыңыз. Шлюзге ping же жашыл IKE абалы бул тест эмес.

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

Артка кайтаруу ошол тартипти тескери бурат. Жумуш жүгүнүн ички тармагынын маршрутун акырында алып салыңыз, мурунку селекторлорду калыбына келтиргенден кийин, булактарын эми коргобогон шлюзга көрсөткөн ички тармак калтырбаш үчүн. Бул келишимдер аткарылганда өзүн-өзү жайгаштыруу шлюз хостунан көбүрөөк кызмат кыла алат, ал эми AWS башкарган Site-to-Site VPN — strongSwan кардар шлюзи тарапта отура ала турган башка операциялык модель.

Тектеш макалалар