Проверката на източник/дестинация е една порта, а не целият път на VPN
Инстанцията за препращане се нуждае от разрешение в AWS, както и от маршрути в Linux и правила на защитната стена. Проверете валидирането на източник/дестинация на инстанцията, която препраща.
VPN завършва на EC2 инстанция, можете да достигнете адреса на тунела на тази инстанция, а трафикът, който трябва да мине през нея към друг частен хост, изчезва. Това са два различни теста и смесването им губи часове. Първият пита дали можете да достигнете инстанцията; вторият изисква тя да препраща трафик за дестинация, която не е нейна, което изисква препращане в Linux, политика на защитната стена, маршрут от другата страна и разрешение на ниво AWS, което няма нищо общо с гостевата операционна система. Нищо в конзолата не обръща внимание на тази разлика. Симптомът изглежда като повреда в маршрутизацията и обикновено не е.
Разделете двата теста, преди да промените нещо
Достигането до шлюза доказва тунела, маршрута до адреса му и групата за сигурност, която разрешава обмена. Препращането за друг хост не доказва нищо от това: то използва различен адрес на източник, различна дестинация и инстанция, действаща в роля, за която не е задължително създадена. Запишете двата теста поотделно и отбележете кой се проваля, защото корекцията за всеки е в различна конзола. Инстанция шлюз, създадена само за завършване на тунели, няма причина да препраща за нищо друго и настройките ѝ по подразбиране отразяват това. Затова вторият тест се нуждае от собствена настройка, а не от малка корекция на първия.
Ping, който работи към шлюза, и ping, който се проваля към хоста отвъд него, не е периодичен проблем. Това е очакваното поведение на инстанция, на която не е казано, че може да препраща.
Запишете пътя, преди да пипате настройка
Запишете префикса на клиента, инстанцията за препращане или мрежовия интерфейс, целевата подмрежа и маршрута за отговор. Запис в таблицата с маршрути на VPC, който сочи към инстанция, не конфигурира операционната система на инстанцията да препраща, а гостево ядро с включено препращане не създава маршрут във VPC. И двата края на тази връзка трябва да съществуват и те се редактират на различни места от хора с различен достъп.
След това прегледайте настройката за проверка на източник/дестинация на действителния компонент за препращане, а не на всяка инстанция във VPC. AWS документира защо инстанция, която препраща трафик за други, трябва да има изключена тази проверка, както и защо настройката е решение за всяка инстанция, а не стойност по подразбиране за целия VPC.
Четири граници и проверката е само една от тях
Третирайте пътя като четири въпроса и отговаряйте на тях по ред. Първият неуспешен отговор показва къде е работата и никой от останалите няма да го компенсира.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
Редът е важен, защото проверката е евтина: маршрутите се виждат на една страница, проверката е един атрибут, а мнението на дестинацията обикновено е последното, за което някой пита.
Преводът променя кой източник вижда дестинацията
Маршрутизираният дизайн запазва адреса на източника на клиента, затова дестинацията се нуждае от обратен маршрут към префикса на клиента. Преведеният дизайн вместо това представя адреса на шлюза, което премахва това изискване и го заменя с таблица на състоянията на шлюза. Решете според архитектурата, която възнамерявате, вместо да добавяте превод, защото несвързан пример го е използвал и е изглеждал работещ.
Ако превеждате, ограничете правилото до префикса на клиента и предвидената дестинация. Ако запазвате, потвърдете, че далечната страна наистина знае маршрута, вместо да предполагате, че ще го научи.
Тествайте от оригиналния клиент, след което запазете промяната
Заявка, генерирана на шлюза, може да успее, докато препратена заявка се проваля, защото това е различен източник и различен случай на препращане. След целенасочена корекция повторете точния тест клиент-към-ресурс, който се провали, от същия клиент, и потвърдете, че отговорът се връща, а не само че заявката е пристигнала.
Накрая, поставете настройката в управляваната конфигурация на шлюза, така че заместваща инстанция да я получи. Успешен тест, който зависи от ръчно изключение, е тест, който изтича при следващото преизграждане, а човекът, който го е открил, няма да е там, за да си спомни защо.