Сайт към сайт или отдалечен достъп през VPN: какво свързва всяко от двете

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

Две решения, две граници

Нито едно от решенията не разширява широкомовния домейн на LAN. Устройствата от другата страна не се появяват в локален списък за откриване и очакването да го правят е първото допускане, от което трябва да се откажете. Частните DNS имена, които публикувате умишлено, са по-предвидими от всеки протокол за откриване и оцеляват при смяна на доставчика.

Вземете 10.10.0.0/24 на единия сайт и 10.20.0.0/24 на другия. Шлюз A се нуждае от маршрут или селектор на трафик, който изпраща префикса 10.20.0.0/24 в тунела, а шлюз B се нуждае от огледалното му изображение. След това хостовете от двете страни използват обикновена IP свързаност и никога не научават, че съществува тунел. Тази невидимост е функцията и именно затова отказите изглеждат като обикновени мрежови грешки, а не като грешки на тунела.

Базирано на политика и базирано на маршрут не е един и същ тунел

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

StrongSwan показва и двете гледни точки директно и съвместното им четене е начинът да разберете кой модел всъщност сте внедрили.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

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

Планирайте адресирането преди тунела

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

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

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

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

Шлюзът трябва да е готов да препраща пакети между интерфейса на тунела и LAN интерфейса и двете посоки се нуждаят от политика, която разрешава услугата. В Linux това са две отделни настройки, плюс правилата на защитната стена, които решават дали препращеният поток е разрешен изобщо.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

Приемащият хост добавя трети слой: собствената му защитна стена все още трябва да приеме клиент от отдалечената подмрежа. Файлов сървър, който разрешава само своята локална /24, ще отхвърли препратен трафик от 10.20.0.7, колкото и здрав да изглежда тунелът, и това отхвърляне лесно се разчита като отказ на маршрутизацията.

Тествайте от хост, а не от шлюза

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

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

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

Изберете дизайна по въпроса, на който отговаряте: свързвате мрежи или допускате устройства? Всичко останало, включително кой доставчик конфигурирате, следва от този отговор.