Двоструки стек VPN базени: адресирање обе фамилије у strongSwan-у

Унутрашњи IPv4 и IPv6 базени, заштићени префикси и фамилија спољашњег тунела су три одвојене одлуке. Испланирајте сваку пре него што то назовете двоструким стеком.

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

Већина забуне долази отуда што се реч двоструки стек примењује на дизајн који је двоструки стек само на једном месту. Услуга може бити двоструки стек изнутра, једноструки стек на својој спољашњој адреси, и ипак савршено добро радити за клијенте. Оно што не може јесте да ради случајно.

Две фамилије унутра, једна стаза споља

Спољашња веза је IKE преко UDP-а и потребна јој је једна доступна фамилија адреса са места на ком се клијент налази. Унутрашња IPv6 адреса не захтева провајдера са IPv6 подршком, јер је унутрашњи пакет корисни терет унутар спољашњег. Многа радна постављања преносе IPv6 префиксе кроз узлазни канал који подржава само IPv4.

Оно што спољашња стаза заиста ограничава јесте доступност и пролаз кроз NAT. Ако приступник оглашава само IPv4 адресу, клијент на мрежи само са IPv6 не може се уопште повезати, без обзира које базене конфигурисали. Изаберите спољашњу фамилију према својој клијентској популацији, а не према унутрашњем плану адреса.

Дајте клијенту адресу у свакој фамилији

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

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Вредност vips тражи адресу из сваке фамилије, а листа базена одлучује одакле те адресе долазе. Документација strongSwan-а о виртуелним IP адресама покрива више захтева и доделу базена, укључујући и то да клијент који тражи одређену адресу исказује само преференцију коју одговарајућа страна може надјачати. Не градите правило приступа које претпоставља да клијент увек добија исту вредност.

Генеришите сопствени јединствени локални префикс уместо да копирате пример. Две организације које обе fd42::/16 уведу, откриће колизију при првом међусобном повезивању, а дијагностиковање тога није пријатно.

Селектори описују одредишта, не изворе

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

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

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

DNS и повратна стаза одлучују да ли то изгледа завршено

Одговори резолвера независни су од транспорта којим се до резолвера долази. Име може вратити A запис, AAAA запис или обоје, а клијент бира према сопственим правилима преференције. Ако интерни сервис објављује AAAA запис али ништа не рутира тај префикс, клијенти на мрежама двоструког стека прво ће покушати IPv6 стазу и седети тамо док не пропадне. Ништа у конфигурацији тунела не изгледа погрешно док се то дешава.

Зато одредите по имену које фамилије треба да буду употребљиве, па проверите да је одговарајући префикс у селектору и да има повратну руту. То је одлука за сваки сервис појединачно. Објављивање оба типа записа без разлике је начин на који радни сервис само са IPv4 почиње да истиче време половини својих корисника.

Проверите обе фамилије пре него што то прогласите готовим

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

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Прве две команде показују успостављене дете SA и који базени још имају доступне адресе, па план који ради за првог клијента а пада за десетог постаје видљив. Последње две показују да ли је клијент добио глобалну IPv6 адресу из базена и куда би саобраћај до заштићеног префикса заиста ишао. Упоредите додељену адресу са базеном који сте конфигурисали, а не са адресом којој сте се надали. Ако је одговарајућа страна под својом политиком изабрала другу вредност, руте и правила заштитног зида и даље морају одговарати њеном избору.

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

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