Пълният тунел в 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, копирано от друг шлюз, променя много повече потоци, отколкото авторът му е възнамерявал. Напишете правилото само за клиентския пул и оставете коментар защо съществува.

На клиента потвърдете маршрутите, които бекендът е инсталирал, а не маршрутите, които сте предположили. Мениджър с изключено инсталиране на маршрути се нуждае от схема за маршрутизация, поддържана на ръка, и тази схема трябва да се обновява при всяка промяна на тунела. Проверявайте таблицата за маршрутизация след повторно свързване, не само след прясно зареждане.

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

Двойката селектори покрива IPv4 и нищо друго. IPv6, DNS и всяка политика на ниво приложение са отделни решения, които широкият IPv4 селектор тихо игнорира. Тунел, който пренася всеки IPv4 пакет, все още може да изтече всяко търсене на име.

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Потвърдете веригата с тези две команди плюс договорените селектори от списъка по-горе. Ако traceroute показва локалния рутер като първи хоп, трафикът не използва тунела, каквото и да твърдят селекторите. Интернет достъпът е пълен само когато избраният трафик е допуснат, препредаден и върнат през проектирания шлюз. Намирането на 0.0.0.0/0 в профил е началото на тази верига, а не доказателството ѝ.

Подобни статии