Праверка крыніцы/прызначэння — адна брама, а не ўвесь шлях VPN

VPN завяршаецца на інстанцыі EC2, вы можаце дасягнуць адраса тунелю гэтай інстанцыі, а трафік, які павінен прайсці праз яе да іншага прыватнага хаста, знікае. Гэта два розныя тэсты, і іх змешванне марнуе гадзіны. Першы пытае, ці можаце вы дасягнуць інстанцыі; другі патрабуе, каб яна перасылала трафік для прызначэння, якое не з'яўляецца яе ўласным, што патрабуе перасылкі Linux, палітыкі міжсеткавага экрана, маршруту на далёкім баку і дазволу ўзроўню AWS, які не мае нічога агульнага з гоставымі аперацыйнымі сістэмамі. Нішто ў кансолі не звяртае ўвагі на гэтую розніцу. Сімптом выглядае як збой маршрутызацыі, і звычайна гэта не так.

Аддзяліце два тэсты, перш чым нешта змяняць

Даход да шлюза даказвае тунель, маршрут да яго адраса і групу бяспекі, якая дазваляе абмен. Перасылка для іншага хаста не даказвае нічога з гэтага: яна задзейнічае іншы адрас крыніцы, іншае прызначэнне і інстанцыю, якая дзейнічае ў ролі, для якой яна не абавязкова стваралася. Запішыце два тэсты асобна і адзначце, які з іх не прайшоў, бо выпраўленне для кожнага знаходзіцца ў рознай кансолі. Інстанцыя шлюза, створаная толькі для завяршэння тунеляў, не мае прычыны перасылаць што-небудзь іншае, і яе прадвызначаныя значэнні гэта адлюстроўваюць. Менавіта таму другі тэст патрабуе ўласнай налады, а не дробнай папраўкі першага.

Пінг, які працуе да шлюза, і пінг, які не працуе да хаста за ім, — гэта не перамежны праблема. Гэта чаканыя паводзіны інстанцыі, якой не паведамілі, што яна можа перасылаць.

Запішыце шлях, перш чым кранаць наладу

Зафіксуйце прэфікс кліента, інстанцыю перасылкі або сеткавы інтэрфейс, мэтавую падсетку і маршрут адказу. Запіс у табліцы маршрутаў VPC, які паказвае на інстанцыю, не наладжвае аперацыйную сістэму інстанцыі на перасылку, а ядро госця з уключанай перасылкай не стварае маршрут VPC. Абодва бакі гэтай сувязі павінны існаваць, і яны рэдагуюцца ў розных месцах людзьмі з розным доступам.

Затым праверце наладу праверкі крыніцы/прызначэння на фактычным кампаненце перасылкі, а не на кожнай інстанцыі ў VPC. AWS дакументуе, чаму інстанцыі, якая перасылае трафік за іншых, трэба адключыць гэтую праверку, а таксама чаму гэтая налада — рашэнне для кожнай інстанцыі, а не прадвызначанае для ўсяго VPC.

Чатыры межы, і праверка — толькі адзін з іх

Разглядайце шлях як чатыры пытанні і адказвайце на іх па парадку. Першы няўдалы адказ — гэта месца працы, і нішто іншае яго не кампенсуе.

Парадак важны, бо праверыць танна: маршруты бачныя на адной старонцы, праверка — гэта адзін атрыбут, а думка прызначэння звычайна апошняе, пра што хто-небудзь пытае.

Пераклад змяняе, якую крыніцу бачыць прызначэнне

Маршрутызаваны дызайн захоўвае адрас крыніцы кліента, таму прызначэнню патрэбны зваротны маршрут да прэфікса кліента. Перакладзены дызайн замест гэтага падае адрас шлюза, што здымае гэтую патрабаванне і замяняе яго табліцай станаў на шлюзе. Вырашайце згодна з архітэктурай, якую маеце намеры, а не дадавайце пераклад таму, што непавязаны прыклад яго выкарыстаў і выглядаў працоўным.

Калі вы перакладаеце, абмяжуйце правіла прэфіксам кліента і меркаваным прызначэннем. Калі вы захоўваеце, пацвердзіце, што далёкі бок сапраўды ведае маршрут, а не мяркуйце, што ён яго вывучыць.

Тэстуйце з арыгінальнага кліента, затым захавайце змяненне

Запыт, створаны на шлюзе, можа ажыццявіцца, тады як перасланы запыт не, бо гэта іншая крыніца і іншы выпадак перасылкі. Пасля мэтанакіраванага выпраўлення паўтарыце дакладны тэст кліент-рэсурс, які не прайшоў, з таго ж кліента, і пацвердзіце, што адказ вяртаецца, а не толькі тое, што запыт дайшоў.

Нарэшце, змясціце наладу ў кіраваную канфігурацыю шлюза, каб яна даставалася заменнай інстанцыі. Паспяховы тэст, які залежыць ад ручной выняткі, — гэта тэст, які заканчваецца пры наступнай перабудове, і чалавек, які яго выявіў, не будзе там, каб успомніць чаму.