Plena tunelo en strongSwan bezonas 0.0.0.0/0 ĉe ambaŭ partneroj

Plena tunelo bezonas 0.0.0.0/0 kiel remote_ts de la kliento kaj kiel local_ts de la pordego, krome plusendado, NAT kaj revena itinero. Kontrolu ĉiujn kvar.

strongSwan-ligilo, kiu funkcias por unu privata subreto, ne transportos interretan trafikon nur ĉar iu redaktis unu linion. Plena tunelo estas interkonsento inter du partneroj pri tio, kiujn adresojn la child SA protektas, kaj ĉiu partnero nomas la alian flankon rilate al si mem. Faru unu flankon ĝusta kaj la alian malĝusta, kaj la child SA aŭ ne leviĝos aŭ leviĝos pli mallarĝa ol celite. La kvin kontroloj sube sekvas tiun interkonsenton de la kliento, tra la pordego kaj eksteren al la interreto.

Kontrolu unue la selektilon de la kliento

La kliento priskribas tion, kion ĝi volas protekti ĉe la fora flanko, kiel remote_ts, kaj ĉio, kion ĝi sendas, devenas de ĝia propra asignita adreso. Por interreta trafiko tiu valoro devas kovri la celojn, kiujn la uzanto efektive atingos, kio praktike signifas la tutan IPv4-spacon. Kliento, kiu ankoraŭ listigas unu subreton, petas dividitan tunnelon, kiel ajn la profilo nomiĝas en la interfaco. La fonta flanko kutime estas dynamic ĉar la adreso estas asignita ĉe konektiĝo. Fiksa fonto skribita tie rompiĝas tuj kiam la adresaro ŝanĝiĝas.

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

La fragmento ne estas kompleta konekta dosiero, kaj ĉi tiu supozas, ke aŭtentikigo, identecoj kaj la naĝejo de virtualaj adresoj jam estas agorditaj. La fonta selektilo de la kliento kaj la adreso, kiun la servilo asignas, ankoraŭ devas kongrui, alie la child SA leviĝos kun amplekso, kiun neniu flanko atendis. Ŝargu ĝin per swanctl --load-all kaj legu la eligon antaŭ ol supozi sukceson. Dosiero, kiu analiziĝas, ankoraŭ povas esti malakceptita pro selektilo, kiu ne interkovras la proponon de la partnero.

Kontrolu la selektilon de la pordego ĉe ĝia propra flanko

La pordego legas la saman koncepton el la kontraŭa direkto. Interretaj celoj estas lokaj por la pordego, do ĝia local_ts estas la larĝa kaj remote_ts priskribas la klientan adresaron. Tiu inversigo estas la plej ofta eraro en plena-tunela agordo, kaj ĝi travivas revizion ĉar ambaŭ linioj aspektas kredindaj aparte.

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

Kopii la klientan fragmenton en la pordegan dosieron produktas selektilan paron, kiu priskribas nenion utilan, ĉar ambaŭ flankoj pretendus la saman rolon. La gvidilo pri plusendado de strongSwan eksplicite dokumentas la parigon de kliento kaj pordego, kaj indas legi ĝin apud la konekta dosiero anstataŭ post la malsukceso. La pordega dosiero ankaŭ bezonas la difinon de la adresaro, al kiu rilatas remote_ts. Selektilo, kiu nomas neekzistantan adresaron, ŝargiĝas sen plendo kaj malsukcesas ĉe konekto.

La malnova ipsec.conf uzas maldekstrajn kaj dekstrajn rolojn kun malsamaj ŝlosiloj, kaj linio rightsubnet ne estas rekta anstataŭaĵo por la swanctl-valoro. Tenu la du sintaksojn en apartaj dosieroj anstataŭ enmeti unu en la alian. Miksi ilin en unu dosierujo estas la maniero, kiel funkcianta konekto silente reiri post restarto.

Kontrolu la intertraktitan child SA, ne la dosieron

Konservita agordo pruvas intencon kaj nenion plu. Partnero povas mallarĝigi la petitan, kaj ekzistanta child SA ne anstataŭiĝas nur ĉar la dosiero sub ĝi ŝanĝiĝis. Konfirmu, kio efektive estas instalita, antaŭ ol ŝanĝi ion alian.

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

La unua komando montras, kion ŝargis la demono, la dua montras la establitajn child SA-ojn, kaj la tria montras la politikojn, kiujn la kerno aplikos. Se la dosiero diras 0.0.0.0/0 kaj la listo montras unu subreton, la intertraktado mallarĝigis la amplekson, kaj relegi la dosieron ne klarigos tion. Finiĝu la child, restartigu ĝin, kaj komparu ĉiujn tri eligojn denove. Child, kiu revenas kun la sama mallarĝa amplekso, estas mallarĝigata de la fora flanko anstataŭ de la loka dosiero, kaj tio estas konversacio kun la alia administranto anstataŭ loka ŝanĝo.

Legu ambaŭ direktojn en la politika listo, ĉar tunelo, kiu instalas unu direkton kaj ne la alian, estas enkursiga problemo en agorda kostumo. La antaŭaj kaj malantaŭaj politikoj devas nomi la saman selektilan paron en spegula bildo, kaj mankanta spegulo estas difekto en la demono aŭ en la propono, ne en la selektila teksto.

Kontrolu plusendadon kaj la revenan itineron

Selektilo permesas trafikon al la pordego; ĝi ne igas la pordegon plusendi tiun trafikon plu. Plusendado devas esti ŝaltita, la fajroŝirmilo devas permesi la fluon, kaj la respondo devas trovi sian vojon reen al la klienta adresaro. Tiuj estas tri apartaj postuloj, kaj ĉiu malsukcesas kun malsama simptomo. Mankanta plusenda regulo kondutas kiel nigra truo, dum mankanta revena itinero kondutas kiel unudirekta tunelo.

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

Privataj klientaj adresoj kutime bezonas intencan fonttradukon antaŭ ol ili povas lasi publikan interfacon, dum eksplicite enkursigita asigno bezonas alian traktadon. Se NAT estas en ludo, konservu la subtenatajn esceptojn de la efektivigo, por ke trafiko, kiun sekureca politiko devus inspekti, ne tradukiĝu preter ĝi. Larĝa masquerade-regulo kopiita de alia pordego ŝanĝas multe pli da fluoj ol ĝia aŭtoro intencis. Skribu la regulon nur por la klienta adresaro kaj lasu komenton klarigantan, kial ĝi ekzistas.

Ĉe la kliento konfirmu la itinerojn, kiujn instalita la backend, ne la itinerojn, kiujn vi supozis. Administrilo kun malŝaltita itinera instalado bezonas mane prizorgatan enkursigan dezajnon, kaj tiu dezajno devas esti ĝisdatigata ĉiam, kiam la tunelo ŝanĝiĝas. Kontrolu la enkursigan tabelon post rekonekto, ne nur post freŝa praŝargo.

Kontrolu, kion la tunelo ankoraŭ ne kovras

La selektila paro kovras IPv4 kaj nenion alian. IPv6, DNS kaj ajna aplikaĵnivela politiko estas apartaj decidoj, kiujn larĝa IPv4-selektilo silente ignoras. Tunelo, kiu portas ĉiun IPv4-pakon, ankoraŭ povas liki ĉiun nomserĉon.

Indiku eksplicite la celatan DNS-vojon, ĉar plena tunelo, kiu ankoraŭ solvas nomojn per la loka solvilo, likas demandojn ekster la tunelo kaj rompas privatajn nomojn. Se la kliento ricevas IPv6-adreson, tiu adresa familio bezonas la saman traktadon, alie la gastiganto preferos vojon, kiun la tunelo ne protektas. Testu per nomo, kiun nur la privata flanko povas respondi, kaj traktu publikan respondon kiel likon.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Konfirmu la ĉenon per tiuj du komandoj plus la intertraktitaj selektiloj el la listo supre. Se la traceroute montras la lokan enkursigilon kiel unuan salton, la trafiko ne uzas la tunnelon, kion ajn asertas la selektiloj. Interreta aliro estas kompleta nur kiam la elektita trafiko estas akceptata, plusendata kaj revenigata tra la planita pordego. Trovi 0.0.0.0/0 en profilo estas la komenco de tiu ĉeno, ne ĝia pruvo.

Rilataj artikoloj