Зашто клијенти Access Server-а нису доступни из LAN-а

Лаптоп се повезује, тунел је подигнут, а захтеви ка интерној услузи висе при повезивању. На самој услузи захтев долази са адресе као 10.90.0.25, одговор одлази ка подразумеваном пролазу и ништа се не враћа, јер тај пролаз појма нема где се налази 10.90.0.25. Са друге стране иста грешка изгледа као интерни домаћин који не може да пингује повезаног клијента. Оба су један објекат који недостаје: повратна рута ка базену VPN клијената, коју само приватна мрежа може да дода.

Прочитајте адресу извора коју услуга види

То једно поље одлучује о свему осталом. Ако интерна услуга види адресу базена, Access Server рутира уместо да скрива саобраћај клијената, и сваки одговор мора бити рутиран назад у базен. Ако уместо тога види сопствену приватну адресу сервера, сервер маскира и повратни пут већ ради, али по цени губитка сваког идентитета по клијенту у дневницима и правилима приступа услуге.

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

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

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

Додајте руту тамо где се одлучује о одговору

Рута припада пролазу који интерна услуга већ користи, не услузи, осим ако она сама не рутира сопствени саобраћај. Усмерите је ка доступној приватној адреси Access Server-а, која се разликује од адресе тунела коју има клијент.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

Учините је трајном и држите величине базена искреним. Два несусетна базена захтевају две руте, а базен који израсте изнад конфигурисаног префикса тихо ствара клијенте чији одговори немају где да оду. Ако ви контролишете опсеге базена, изаберите сажетак који можете да рутирате једном и да оставите.

Прослеђивање и филтери морају да се слажу са рутом

Рутирање је само половина пута. Серверу мора бити дозвољено да прослеђује између тунела и приватног интерфејса, што на Linux-у значи net.ipv4.ip_forward плус ланац прослеђивања који дозвољава пар интерфејса, а на очврслом домаћину обично посебно јасно правило за сваки смер.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Филтрирање са стањем објашњава симптом који људе води на погрешан пут. Одговор унутар успостављеног тока не захтева ново улазно правило, па веза која виси после SYN-ACK није блокирана правилом прихватања које недостаје; она се одбацује или погрешно рутира. Задржите ту разлику, јер она раздваја промену рутирања од промене firewall-а.

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

Рутирано или маскирано: изаберите свесно

Рутирани режим чува адресу базена клијента на услузи, што омогућава евидентирање и политику по клијенту, а заузврат свака интерна мрежа која мора да одговори клијенту захтева руту базена. Маскирани режим уклања тај захтев јер се одговори враћају на сервер, али услуга више не разликује један клијент од другог и не може ништа да покрене ка одређеном клијенту.

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

Подмрежа иза клијента је одвојен задатак

Достизање уређаја у сопственом LAN-у лаптопа није исто као достизање адресе тунела лаптопа. То захтева да клијент делује као пролаз подмреже: декларисана мрежа на страни клијента, омогућено прослеђивање у оперативном систему клијента, и рута у том LAN-у назад ка клијенту. Додавање руте приватне мреже за кућни опсег лаптопа то не чини и ствара сукобе када два корисника имају исти кућни опсег.

Смер је такође питање политике. Дозвола клијенту да отвори везу ка интерној услузи не дозвољава аутоматски интерном домаћину да отвори везу ка том клијенту. Проверите политику приступа сервера и firewall домаћина клијента пре него што закључите да је пут покварен.

Проверите једним током и једним снимком

Докажите пут једном везом уместо општим тестом достижности. Посматрајте исти ток на оба краја: захтев који пристиже у услугу и одговор који је напушта.

tcpdump -ni any host 10.90.0.25 and port 443

Пре поправке снимак показује како одговор одлази ка пролазу који га неће рутирати. После поправке одговор одлази ка серверу и ток се завршава. Затим потврдите руту коју би пролаз користио за другу адресу клијента, да се непокривени базен појави сада, а не за недељу дана.

Завршите са четири провере које ово затварају: адреса извора на услузи одговара режиму који сте намеравали, пролаз има руту ка сваком базену у употреби, прослеђивање и филтери дозвољавају оба смера, и један стварни ток прође од почетка до краја. Често постављана питања о рутирању Access Server-а износи исти принцип за инсталирано издање, чији подржани конфигурациони интерфејс може да се разликује од старијих упутстава.