Отварање 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 описују страну повратне руте и превођења исте границе, што је опет трећа одлука.

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