Cloud VPN-grinzen dy'tst net ôfstelle kinst: IKE-libben en peer-NAT

Jou it fiere apparaat in libben fan 24 oere foar faze 1 en de Cloud VPN-tunnel bliuwt del, ek al is alles oan Google syn kant goed konfigurearre. De peer stelt in wearde foar dy’t de responder net akseptearje sil, dus de ûnderhanneling mislearret hielendal of begjint einleas op ’e nij. Cloud VPN beheint faze 1 ta 36,000 sekonden, tsien oere, en dy limyt is gjin ynstelling dy’tst ferheegje kinst. De feroaring heart by it fiere apparaat.

De peer freget, de responder beslút

IKE is in oefening yn it byinoar passen fan twa sets foarstellen. De tunnel ûntstiet allinnich dêr’t de sets oerlaapje binnen de grinzen dy’t de responder akseptearret, en dêrom jout in libben bûten it berik hielendal gjin dieltunnel. De gewoane flater is om de konfiguraasje fan ’e peer as in winsklijst te behanneljen ynstee fan as in foarstel. In lege trochsneed lit de tunnel del, hoe goed de rûtes en selektors ek binne.

Lês de eigen steat fan de tunnel foardatst in saak iepenest, want de detaillearre status neamt meast de faze dy’t mislearre is:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Fergelykje wat weromkomt mei de stipe set foar dyn gateway-type en IKE-ferzje, en skriuw beide ferkiersselektors dêr op wylstst der bist. In selektor-misferhâlding jout itselde symptoom fan in dellein tunnel as in algoritme-misferhâlding, en oars as it algoritme is dy fan dy om te reparearjen.

36,000 sekonden is it plafon

Faze 1 stopet by 36,000 sekonden. In apparaat dat op 86,400 stiet freget wat de responder nea akseptearje sil, en op ’e nij besykje feroaret syn miening net. Draai it fiere foarstel werom binnen it berik en deselde konfiguraasje komt ta stân; de asymmetry is de hiele les, wantst moatst dyn eigen wearde ferleegje en kinst dy fan Google net ferheegje.

Skriuw de keazen wearde yn ’e ûntwerpnotysjes. Oars werhellet de folgjende yngenieur it eksperimint fan 24 oere en rint tsjin deselde muorre.

De stipe set wurdt publisearre per gateway-type en IKE-ferzje yn ’e Cloud VPN-oersjoch, dus lês de seksje foar dyn topology ynstee fan in algemiene IKE-gids.

In tunnel dy’t neffens skema falt

Faze 2 hâldt him oars: as de beide einen it net iens binne, folget kaaifernijing it koartere interval. In peer dy’t de misferhâlding as fataal sjocht lit de tunnel gewurde falle, sadat ien misferhâlding as twa losse fouten lykje kin. Sjoch nei it ritme fan kaaifernijing, net allinnich nei de earste ferbining. In tunnel dy’t opkomt en dan yn in regelmatich tempo omfalt, is faker in libbensmisferhâlding as in rûtefout.

Korrelearje dy fal-tiidstimpels mei de eigen logs fan ’e peer foardatst wat feroarest, want in selektor- of rûteferoaring kin itselde ritme neibeare. As it tempo by de faze 2-timer past, is de oarsaak fûn sûnder in foarstel oan te reitsjen.

De sets komme fan it gateway-type

Sifer- en yntegriteitsets binne gjin profyl per tunnel datst bewurkest sa’t strongSwan dy talit. Do kiest se per gateway-type en IKE-ferzje, en it sykjen nei in profyl dat net bestiet fergriemt in middei.

In ferâldere apparaat dat neat binnen de stipe set biedt lit twa earlike wegen: ferfang it apparaat, of einigje op in software-gateway dy’tst sels behearst en rûte fan dêr nei de VPC. Al it oare is in omwei dy’t de folgjende beoardieling net hellet.

Ien ekstern adres per apparaat

It eksterne adres fan ’e peer moat ien-op-ien op syn ynterne adres mappe. In oerbelêste PAT-pool kin net wurkje, want ferskate hosts efter ien iepenbier adres jouwe de responder gjin manier om se te skieden. Dêr’t ferskate hosts in adres diele moatte, moat de tunnel einigje op in plak dat se útinoar hâlde kin.

Hâld dat eksterne adres ek stabyl. Ferpleats it apparaat efter in oare NAT en de ferbining brekt, ek al past elk foarstel noch. It is wurdich om op te skriuwen hokker wearden fan Google binne en hokker fan dy: libbens, sets en ien-op-ien NAT binne fêst oan harren kant, wylst foarstellen, selektors, rûtes en BGP-prioriteiten fan dy binne.