Пун тунел Access Server-а на EC2: зашто један пољe за потврду није довољно

Искључивање провере извора и одредишта на EC2 инстанци је најчешће понављан одговор на питања о интернет излазу Access Server-а и само по себи не чини ништа за ваше клијенте. Провера је AWS ограничење прослеђивања: омогућава инстанци да прихвати пакете чији извор или одредиште није њена сопствена адреса. Она не говори клијенту Access Server-а да шаље интернет саобраћај кроз тунел, не ствара путању нагоре и не додаје NAT. Мит је да је поље за потврду сама функција.

Шта провера заправо контролише

Сваки EC2 мрежни интерфејс одбацује саобраћај који није упућен њему, осим ако инстанца ради као рутер, NAT уређај или VPN пролаз и ви не искључите ту проверу. Искључивање даје дозволу за прослеђивање. Дозвола није конфигурација: инстанци је и даље потребна путања до интернет пролаза или NAT уређаја, табели путања VPC-а је и даље потребан одговарајући запис, сигурносне групе и даље морају да дозволе ток, а сервер и даље мора да преведе или усмери повратни саобраћај.

Проверите тренутну вредност помоћу aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck пре него што било шта промените. Ако је промените у конзоли, промените је зато што инстанца прослеђује за друге, а не зато што клијент не може да дође на интернет.

Политика усмеравања клијента припада Access Server-у

У Access Server-у 3 отворите Access Controls и пронађите одељак Internet Access and DNS. Избор Internet Gateway нуди пун или подељен тунел; пун тунел говори клијенту да свој подразумевани саобраћај усмери у VPN, подељен оставља интернет саобраћај на локалној путањи клијента. Сачувајте и примените кроз радни ток производа, затим поново повежите пробног клијента, јер се политика доставља у тренутку повезивања.

Старија издања користе друге меније, а неке Community OpenVPN градње немају еквивалентну контролу. Проверите инсталирану главну верзију пре него што потражите екран који не постоји. Затим потврдите шта је клијент добио: профил пуног тунела треба да инсталира подразумевану путању кроз тунел, а профил подељеног тунела не треба.

Пратите пакет након тунела

Када клијент пошаље интернет саобраћај у тунел, сервер мора да га проследи и обично преведе. Access Server управља сопственим NAT и правилима усмеравања, зато читајте стварну конфигурацију уместо да додајете правила Community OpenVPN у генерисане датотеке; неконтролисана правила се преписују или се сукобљавају при следећем ажурирању производа. sudo iptables -t nat -L -n -v или еквивалент за nftables показује шта се заиста преводи.

Страна AWS-а је одвојена путања. Инстанца у јавној подмрежи долази до интернет пролаза директно и задржава своју јавну адресу или еластични IP. Инстанци у приватној подмрежи потребна је путања до NAT пролаза или NAT инстанце, а NAT уређају је потребна сопствена путања до интернет пролаза. Прикључивање интернет пролаза на VPC само по себи не даје ниједном приватном извору јавну повратну адресу, зато иста поставка Access Server-а ради у једној подмрежи, а у другој тихо не успева.

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

Држите IP излаз и DNS одвојено

Тестирајте прво литерал адресе, затим име, из исте клијентске апликације. Ако curl -4 https://checkip.amazonaws.com врати јавну адресу, али имена домаћина не успевају, тунел и NAT путања раде, а проблем је у DNS-у: послати резолвер, стање резолвера клијента или сигурносна група која блокира резолвер. DNS подешавања Access Server-а су у истој Internet Access области, али путују другим путем кроз код.

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

Не дозволите да једно поље затвори истрагу

IPv6 је одвојена одлука. Политика пуног тунела за IPv4 не говори ништа о томе да ли се IPv6 преноси, блокира или цури, а клијент са два стека може наставити да користи локалну IPv6 путању док је IPv4 у тунелу. Тестирајте породицу адреса која вам је заиста важна и изричито одлучите да ли другу треба искључити.

На крају, тестирајте искључено стање. Избор пуног тунела описује политику усмеравања док сте повезани, а не шта се дешава када тунел падне. Ако је захтев да никакав саобраћај не побегне изван VPN-а, то је питање kill-switch-а и заштитног зида и захтева сопствени тест, а не закључак из табеле путања.