VPN између локација или удаљени приступ: шта сваки повезује

Оба решења се називају VPN и решавају различите проблеме. Тунел између локација повезује два мрежна пролаза, тако да сваки хост иза њих може да достигне дозвољене адресе на другој страни без инсталирања било чега. Тунел удаљеног приступа повезује појединачне уређаје са мрежом, један клијент у једном тренутку. Поређење је важно јер већина грешака при распоређивању настаје када се једно решење конфигурише очекујући понашање другог, а симптом је обично истек времена на услузи до које је тунел заиста стигао.

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

Ниједно решење не проширује broadcast домен 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

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

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