Отварянето на VPN порта не дава на клиентите достъп до LAN

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

Две вериги, две различни дестинации

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

Целият мит в едно изречение: разрешаването на слушателя не казва нищо за разрешаването на мрежата зад него. Това са две отделни решения с отделни доказателства и име на интерфейс върху двете не ги слива.

Какво всъщност допуска правилото за слушателя

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

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

Тествайте от клиента, никога от шлюза

Тест, създаден на шлюза, следва изходния път на хоста и може да мине, докато пътят за препращане е затворен. Започнете теста от клиента и наблюдавайте двата края на потока.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

Препращането иска три неща, не едно

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

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

Дръжте двата набора правила отделно в документацията

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

Вместо да смятате всеки удостоверен партньор за доверен член на LAN, използвайте тесни правила за онези диапазони на клиенти и услуги, които имат нужда. Бележките за препращане на StrongSwan описват страната на обратния маршрут и транслацията на същата граница, което отново е трето решение.

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