Пун тунел у strongSwan захтева 0.0.0.0/0 на обе стране

Пун тунел захтева 0.0.0.0/0 као remote_ts клијента и local_ts пролаза, плус прослеђивање, NAT и повратну руту. Проверите сва четири.

strongSwan веза која ради за једну приватну подмрежу неће преносити интернет саобраћај само зато што је неко уредио једну линију. Пун тунел је споразум између две стране о томе које адресе штити child SA, и свака страна именује другу у односу на себе. Поставите једну страну исправно, а другу погрешно, и child SA или се неће подићи или ће се подићи ужа него што је планирано. Пет провера испод прате тај споразум од клијента, кроз пролаз, до интернета.

Прво проверите селектор клијента

Клијент описује шта жели да заштити на даљој страни као remote_ts, и све што шаље долази са његове сопствене додељене адресе. За интернет саобраћај та вредност мора да покрије одредишта која ће корисник стварно достићи, што у пракси значи цео IPv4 простор. Клијент који још наводи једну подмрежу тражи подељени тунел, како год се профил звао у интерфејсу. Страна извора је обично dynamic јер се адреса додељује при повезивању. Фиксни извор записан тамо се квари чим се промени скуп адреса.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Овај фрагмент није потпуна датотека везе, и овај претпоставља да су аутентификација, идентитети и скуп виртуелних адреса већ конфигурисани. Селектор извора клијента и адреса коју додељује сервер и даље морају да се поклопе, иначе ће се child SA подићи са обухватом који ниједна страна није очекивала. Учитајте га са swanctl --load-all и прочитајте излаз пре него што претпоставите успех. Датотека која се парсира ипак може бити одбијена због селектора који се не преклапа са предлогом друге стране.

Проверите селектор пролаза на његовој страни

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

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Копирање фрагмента клијента у датотеку пролаза ствара пар селектора који не описује ништа корисно, јер би обе стране тражиле исту улогу. Упутство за прослеђивање strongSwan експлицитно документује упаривање клијента и пролаза, и вреди га читати поред датотеке везе, а не после неуспеха. Датотеци пролаза је потребна и дефиниција скупа на који упућује remote_ts. Селектор који именује непостојећи скуп учитава се без жалбе и не успева при повезивању.

Стари ipsec.conf користи леву и десну улогу са различитим кључевима, а линија rightsubnet није директна замена за вредност swanctl. Држите две синтаксе у одвојеним датотекама уместо да једну убацујете у другу. Мешање у једном директоријуму је начин на који радна веза тихо пада назад после рестарта.

Проверите договорени child SA, не датотеку

Сачувана конфигурација доказује намеру и ништа више. Друга страна може да сузи затражено, а постојећи child SA се не замењује само зато што се датотека под њим променила. Потврдите шта је стварно инсталирано пре него што промените било шта друго.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Прва команда показује шта је демон учитао, друга показује успостављене child SA, а трећа политике које ће језгро применити. Ако датотека каже 0.0.0.0/0, а листа показује једну подмрежу, преговори су сузили обухват и поновно читање датотеке то неће објаснити. Завршите child, поново је покрените и још једном упоредите сва три излаза. Child која се врати са истим уским обухватом сужава се од стране даљег, а не локалне датотеке, и то је разговор са другим администратором, а не локална измена.

Читајте оба смера у листи политика, јер тунел који инсталира један смер, а не други, је проблем рутирања у костиму конфигурације. Политике напред и назад треба да именују исти пар селектора у огледалској слици, а огледало које недостаје је дефект у демону или предлогу, а не у тексту селектора.

Проверите прослеђивање и повратну руту

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Приватне адресе клијената обично захтевају намерно превођење извора пре него што могу да напусте јавни интерфејс, док експлицитно рутирана додела захтева другачији третман. Ако је NAT у игри, задржите изузетке које имплементација подржава, како се саобраћај који безбедносна политика треба да прегледа не би преводио поред ње. Широко masquerade правило копирано са другог пролаза мења много више токова него што је аутор намеравао. Напишите правило само за скуп клијената и оставите коментар зашто постоји.

На клијенту потврдите руте које је инсталирао backend, а не руте које сте претпоставили. Менаџер са искљученим инсталирањем рута захтева ручно одржаван дизајн рутирања, и тај дизајн мора да се ажурира кад год се тунел промени. Проверите табелу рутирања после поновног повезивања, не само после свежег подизања.

Проверите шта тунел још не покрива

Пар селектора покрива IPv4 и ништа друго. IPv6, DNS и било која политика на нивоу апликације су одвојене одлуке које широки IPv4 селектор тихо игнорише. Тунел који преноси сваки IPv4 пакет ипак може да одаје сваку претрагу имена.

Експлицитно наведите предвиђену DNS путању, јер пун тунел који још решава имена преко локалног резолвера одаје упите изван тунела и квари приватна имена. Ако клијент добије IPv6 адресу, том скупу адреса треба исти третман, иначе ће хост преферирати путању коју тунел не штити. Тестирајте именом на које само приватна страна може да одговори, и третирајте јавни одговор као отицање.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Потврдите ланац тим двема командама плус договореним селекторима са листе горе. Ако traceroute показује локални рутер као први скок, саобраћај не користи тунел, ма шта селектори тврдили. Интернет приступ је пун само када се изабрани саобраћај прихвати, проследи и врати кроз пројектовани пролаз. Проналажење 0.0.0.0/0 у профилу је почетак тог ланца, а не његов доказ.

Повезани чланци