Komencu ĉe la filio mem, sur la WAN-stata paĝo de la 4G-vojadirektilo. Se la adreso, kiun vi vidas, kuŝas en la privata gamo de la operatoro anstataŭ en publika, neniu porda plusendo sur tiu skatolo iam lasos la hubon voki internen, kaj la tunelo devas esti konstruita eksteren el la filio. Tiu unu observo decidas la dezajnon. La resto de la laboro estas certigi, ke la hubo rekonas la filion per io pli bona ol adreso, kiu ŝanĝiĝas ĉiun kelkajn horojn.

Kie la tunelo devas komenciĝi

Kontrolu la adreson kontraŭ la komuna adresspaco, kiun operatoroj uzas por sia propra NAT, 100.64.0.0/10, kaj kontraŭ la ordinaraj privataj gamoj. Vidi unu el ili sur movebla suprenligo kutime signifas, ke operatornivela NAT staras inter la filio kaj la interreto, kaj envenantaj konektoj ne disponeblas je neniu prezo, kiun la filio povas pagi. Kiam la WAN-adreso estas publika sed ŝanĝiĝas, vi havas alian, pli facilan problemon.

Dinamika DNS helpas nur en la dua kazo. Ĝi donas al ŝanĝiĝanta publika adreso stabilan nomon por voki, kaj ĝi ne povas krei mapadon, kiun la operatoro neniam provizis. Ĝi tamen indas esti agordita por la publika kazo, ĉar ĝi forigas la ununuran permanan paŝon en renumerado. Kion ĝi ne devas fariĝi, estas la respondo por filio, kiun la operatoro neniam faris atingebla.

Apartigu la adreson, kiun vi vokas, de la identeco, kiun vi kongruas

La hubo bezonas stabilan aferon, ĉe kiu ĝi troveblas, aprobitan fiksan adreson aŭ prizorgatan hostonomon. La filio bezonas stabilan manieron esti rekonata, kaj en IKEv2 tio estas la identeca utilaĵo, kiun ĝi prezentas dum aŭtentikigo, sendepende de la fontadreso, kiun ĝiaj pakaĵoj hazarde portas. Ĉeno kiel @branch-a.vpn.example funkcias kiel tiu identeco eĉ dum la movebla adreso ŝanĝiĝas ĉiuhore.

Tiu ĉeno estas kongruata kun politiko, ne solvata per DNS, do ne atendu serĉon ĉe tunela starigo. La agordo de la hubo devas eksplicite nomi la atendatan identecon, kaj ĉe atestila aŭtentikigo la identeco ankaŭ devas kongrui kun tio, kion la atestilo efektive asertas.

Akcepti iun ajn identecon ĉar la fontadreso ŝajnas kredinda estas la fiaskmaniero, kiun oni devas eviti. Ĉe respondanto tio signifas akcepti iun ajn partneron, kun identeca ĵokero kaj komuna sekreto, kio aŭtentikigas ĉenon anstataŭ aparaton.

Skribu la huban flankon kiel nomitan partneron

En terminoj de strongSwan la respondanta flanko estas konekto kun right=%any, kiu akceptas partneron el iu ajn fontadreso, plus [email protected], kiu fiksas, kion tiu partnero devas deklari esti. Aldonu rightsubnet=10.20.0.0/16 por la LAN-oj de la filio, auto=add por ke la konekto ŝarĝiĝu sen vokiĝo, dpd_delay=30s por viveco, kaj mobike=yes por ke adresŝanĝo povu esti sorbita anstataŭ traktata kiel nova partnero.

Aliaj vendistoj esprimas la samajn objektojn sub diversaj nomoj, kutime dinamika aŭ filibranĉa partnera tipo kun identeca kampo kaj protektita subreta kampo. Plenigu ambaŭ; ĝenerala dinamika markobutono ne estas kongrueca plano.

Tenu la filion kiel inicianton

Ĉe la filio validas la spegula bildo: left=%defaultroute por ke la loka movebla adreso estu uzata tia, kia ĝi nun estas, [email protected] por prezenti la identecon, right=hub.example.com por la stabila huba nomo, kaj auto=start por ke la tunelo suprestiĝu sen homo. Kiam la movebla ligo rekonektiĝas, la filio reiniciatas kaj la hubo kongruas la saman identecon kun la sama politika objekto.

Permesu IKE sur UDP 500, NAT-trapasadon sur UDP 4500, kaj la enkapsuligitan ESP-on, kiu sekvas, ĉe ambaŭ flankoj. Poste lasu ilin permesitaj: regulo, kiu malfermiĝas nur dum labortempo, aspektos kiel intermita tunelo.

Testu la adresŝanĝon, ne nur la unuan manpremon

Levigu la tunelon, konfirmu ĝin, poste devigu la filion al nova adreso per ŝaltado de moveblaj datumoj aŭ aviad-reĝimo dum unu minuto. Observu la sekurec-asocia liston ĉe la hubo kaj kontrolu, ke la adreso de la partnero ŝanĝiĝis dum la identeco ne. Tunelo, kiu funkcias nur ĝis la unua reasigno de la operatoro, tute ne estis testita.

Poste kontrolu la protektitajn subretojn aparte. Konstrupita SA diras, ke la partneroj aŭtentikigis sin; ĝi ne diras, ke la hubo havas itineron al la LAN de la filio aŭ ke la filio akceptas trafikon de la huba flanko. Legu la itineran tabelon kaj la fajroŝirma politikon aparte, poste sendu pingon el gastiganto anstataŭ el la enirejo, ĉar la enirejo estas la malplej reprezenta aparato en iu ajn reto.

Stabila identeco igas la filion politika objekto, kiun la hubo povas nomi. Ĝi ne igas operatoran NAT-adreson atingebla, kaj ĝi ne donas al la resto de la organizo aliron al la filio per si mem.

Rilataj artikoloj