Защо клиентите на 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 и хостовата защитна стена все още трябва да разрешават трафика.

Направете го постоянен и поддържайте размерите на пуловете честни. Два несъседни пула се нуждаят от два маршрута, а пул, който нарасне извън конфигурирания префикс, тихо създава клиенти, чиито отговори няма къде да отидат. Ако контролирате диапазоните на пуловете, изберете обобщение, което можете да маршрутизирате веднъж и да оставите.

Препращането и филтрите трябва да са в съгласие с маршрута

Маршрутизацията е само половината от пътя. Сървърът трябва да има разрешение да препраща между тунела и частния интерфейс, което в Linux означава net.ipv4.ip_forward плюс верига за препращане, която разрешава двойката интерфейси, а на укрепен хост обикновено изрично правило за всяка посока.

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

Филтрирането със състояние обяснява симптом, който отвежда хората по грешен път. Отговорът в установен поток не се нуждае от ново входящо правило, затова връзка, която виси след SYN-ACK, не се блокира от липсващо правило за приемане; тя се отхвърля или маршрутизира погрешно. Пазете това разграничение, защото то отделя промяна в маршрутизацията от промяна в защитната стена.

Асиметричните обратни пътища са по-тихата версия на същия проблем. Ако два маршрута стигат до пула и отговорът поеме този, който излиза от различен интерфейс от този, по който е пристигнала заявката, строгото филтриране на обратния път го отхвърля и потокът се проваля само за някои клиенти.

Маршрутизирано или маскирано: изберете съзнателно

Маршрутизираният режим запазва адреса от пула на клиента в услугата, което прави възможни журналиране и политика за всеки клиент, а в замяна всяка вътрешна мрежа, която трябва да отговори на клиент, се нуждае от маршрута към пула. Маскираният режим премахва това изискване, защото отговорите се връщат към сървъра, но услугата вече не различава един клиент от друг и не може да инициира нищо към конкретен клиент.

Промяната на това поведение на работещ сървър прекратява съществуващите сесии, затова първо тествайте с един клиент и един поток. Ако превключването е правилният отговор, това е решение за конфигурацията на сървъра, а не нещо, което да се заобикаля с добавяне на маршрути, които ще станат ненужни.

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

Достигане до устройство в собствената LAN на лаптопа не е същото като достигане до тунелния адрес на лаптопа. То изисква клиентът да действа като шлюз за подмрежа: декларирана мрежа от страна на клиента, включено препращане в операционната система на клиента и маршрут в тази LAN обратно към клиента. Добавянето на маршрут за частна мрежа към домашния диапазон на лаптопа не прави това и създава конфликти, когато двама потребители имат един и същ домашен диапазон.

Посоката също е въпрос на политика. Разрешението клиент да отвори връзка към вътрешна услуга не позволява автоматично на вътрешен хост да отвори връзка към този клиент. Проверете политиката за достъп на сървъра и хостовата защитна стена на клиента, преди да заключите, че пътят е счупен.

Проверете с един поток и един запис

Докажете пътя с една връзка вместо с общ тест за достъпност. Наблюдавайте същия поток в двата края: заявката, пристигаща в услугата, и отговорът, който я напуска.

tcpdump -ni any host 10.90.0.25 and port 443

Преди поправката записът показва отговора да тръгва към шлюз, който няма да го маршрутизира. След поправката отговорът тръгва към сървъра и потокът завършва. После потвърдете маршрута, който шлюзът би използвал за адрес на втори клиент, за да се появи необхванатият пул сега, а не след седмица.

Завършете с четирите проверки, които приключват въпроса: адресът на източника в услугата съответства на режима, който сте предвидили, шлюзът има маршрут до всеки използван пул, препращането и филтрите разрешават двете посоки и един реален поток завършва от край до край. Често задавани въпроси за маршрутизацията на Access Server излага същия принцип за инсталираното издание, чийто поддържан конфигурационен интерфейс може да се различава от по-старите ръководства.

Подобни статии