VPN се завршава на EC2 инстанци, можете да достигнете адресу тунела те инстанце, а саобраћај који је требало да прође кроз њу ка другом приватном хосту нестаје. То су два различита теста и њихово мешање губи сате. Први пита да ли можете да достигнете инстанцу; други захтева да она прослеђује саобраћај за одредиште које није њено, што захтева прослеђивање у Linux-у, политику заштитног зида, руту на даљој страни и дозволу на нивоу AWS-а која нема никакве везе са гостујућим оперативним системом. Ништа у конзоли не скреће пажњу на ту разлику. Симптом изгледа као квар рутирања и обично није.

Одвојите два теста пре него што било шта промените

Достизање капије доказује тунел, руту до њене адресе и безбедносну групу која дозвољава размену. Прослеђивање за други хост не доказује ништа од тога: користи другу изворну адресу, друго одредиште и инстанцу у улози за коју није нужно изграђена. Запишите два теста одвојено и забележите који не успева, јер се исправка за сваки налази у другој конзоли. Инстанца капије изграђена само за завршавање тунела нема разлога да прослеђује за било шта друго, а њене подразумеване вредности то одражавају. Зато други тест захтева сопствено подешавање, а не малу измену првог.

Пинг који ради ка капији и пинг који не успева ка хосту иза ње нису повремен проблем. То је очекивано понашање инстанце којој није речено да сме да прослеђује.

Запишите пут пре него што дотакнете подешавање

Забележите префикс клијента, инстанцу или мрежни интерфејс за прослеђивање, циљну подмрежу и руту за одговор. Унос у табели рута VPC-а који показује на инстанцу не конфигурише оперативни систем инстанце за прослеђивање, а гостујуће језгро са укљученим прослеђивањем не ствара VPC руту. Оба краја те везе морају да постоје, и она се уређују на различитим местима од људи са различитим приступом.

Затим прегледајте подешавање провере извора/одредишта на стварној компоненти прослеђивања, а не на свакој инстанци у VPC-у. AWS документује зашто инстанца која прослеђује саобраћај за друге мора да има ту проверу искључену, као и зашто је подешавање одлука за сваку инстанцу, а не подразумевана вредност за цео VPC.

Четири границе, а провера је само једна од њих

Третирајте пут као четири питања и одговорите на њих по реду. Први неуспели одговор је место где је посао, и ниједан од осталих га неће надокнадити.

BoundaryQuestion it answers
VPC route tablesDo the destinations and replies select the intended gateway?
Forwarding instanceDo the AWS check and the guest OS both permit forwarding?
Access policyDo security groups, ACLs and host rules allow the exchange?
DestinationCan the service accept that source and return a reply?

Редослед је важан зато што је провера јефтина: руте се виде на једној страници, провера је један атрибут, а мишљење одредишта је обично последње што неко пита.

Превод мења који извор одредиште види

Рутирано решење чува изворну адресу клијента, па је одредишту потребна повратна рута до префикса клијента. Преведено решење уместо тога представља адресу капије, што уклања тај захтев и замењује га табелом стања на капији. Одлучите према архитектури коју намеравате, уместо да додате превод јер га је неки неповезани пример користио и изгледао исправан.

Ако преводите, ограничите правило на префикс клијента и предвиђено одредиште. Ако чувате, потврдите да даља страна заиста зна руту, уместо да претпостављате да ће је научити.

Тестирајте са оригиналног клијента, затим задржите измену

Захтев створен на капији може да успе док прослеђени захтев не успева, јер је то други извор и други случај прослеђивања. После циљане исправке поновите тачно онај тест клијент-до-ресурса који није успео, са истог клијента, и потврдите да се одговор враћа, а не само да је захтев стигао.

На крају, ставите подешавање у управљану конфигурацију капије како би га добила заменска инстанца. Успешан тест који зависи од ручног изузетка је тест који истиче при следећој поновној изградњи, а особа која га је открила неће бити тамо да се сети зашто.

Повезани чланци