Cloud VPN ierobežojumi, kurus nevar noregulēt: IKE darbības laiks un peer NAT

Piešķiriet attālajai ierīcei 24 stundu 1. fāzes darbības laiku, un Cloud VPN tunelis paliks izslēgts, lai gan Google pusē viss ir pareizi konfigurēts. Peer piedāvā vērtību, ko atbildētājs nepieņems, tāpēc sarunas vai nu pilnībā izgāžas, vai sākas no jauna bezgalīgi. Cloud VPN ierobežo 1. fāzi līdz 36,000 sekundēm, tas ir, desmit stundām, un šis ierobežojums nav iestatījums, ko varētu pacelt. Izmaiņas pienākas attālajai ierīcei.

Peer jautā, atbildētājs izlemj

IKE ir divu priekšlikumu kopu saskaņošanas vingrinājums. Tunelis veidojas tikai tur, kur kopas pārklājas atbildētāja pieņemtajās robežās, tāpēc ārpus diapazona esošs darbības laiks nerada nekādu daļēju tuneli. Ierastā kļūda ir uzskatīt peer konfigurāciju par vēlmju sarakstu, nevis priekšlikumu. Tukša krustošanās atstāj tuneli izslēgtu, lai cik pareiza būtu maršrutēšana un selektori.

Pirms lietas atvēršanas izlasiet paša tuneļa stāvokli, jo detalizētais statuss parasti nosauc neizdevušos posmu:

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

Salīdziniet atgriezto ar atbalstīto kopu jūsu vārtejas tipam un IKE versijai, un, kamēr esat tur, pierakstiet abus trafika selektorus. Selektora neatbilstība dod tādus pašus izslēgta tuneļa simptomus kā algoritma neatbilstība, un atšķirībā no algoritma šī ir jālabo jums.

36,000 sekundes ir griesti

1. fāze apstājas pie 36,000 sekundēm. Ierīce, kas iestatīta uz 86,400, prasa kaut ko tādu, kam atbildētājs nekad nepiekritīs, un atkārtošana nemaina viņa viedokli. Atgrieziet attālo priekšlikumu diapazonā, un tā pati konfigurācija izveidosies; asimetrija ir visa mācība, jo savu vērtību jūs varat pazemināt, bet Google vērtību pacelt nevarat.

Ierakstiet izvēlēto vērtību projektēšanas piezīmēs. Citādi nākamais inženieris atkārtos 24 stundu eksperimentu un atdursies pret to pašu sienu.

Atbalstītā kopa tiek publicēta pēc vārtejas tipa un IKE versijas Cloud VPN pārskatā, tāpēc lasiet sadaļu par savu topoloģiju, nevis vispārīgu IKE rokasgrāmatu.

Tunelis, kas krīt pēc grafika

2. fāze uzvedas citādi: kad abi gali nevienojas, atslēgu atjaunošana seko īsākajam intervālam. Peer, kas neatbilstību uzskata par letālu, tā vietā nomet tuneli, tāpēc viena neatbilstība var izskatīties kā divi nesaistīti bojājumi. Vērojiet atslēgu atjaunošanas ritmu, ne tikai pirmo savienojumu. Tunelis, kas uzlec un pēc tam krīt regulārā taktī, biežāk ir darbības laika neatbilstība, nevis maršrutēšanas defekts.

Pirms kaut ko mainīt, sasaistiet tos kritienu laika zīmogus ar paša peer žurnāliem, jo selektora vai maršruta maiņa var atdarināt to pašu ritmu. Ja takts sakrīt ar 2. fāzes taimeri, cēlonis ir atrasts, neaiztiekot priekšlikumu.

Kopas nāk no vārtejas tipa

Šifrēšanas un integritātes kopas nav profils katram tunelim, ko rediģējat, kā to pieļauj strongSwan. Jūs tās izvēlaties pēc vārtejas tipa un IKE versijas, un neesoša profila meklēšana izšķiež pēcpusdienu.

Vecā ierīce, kas neko nepiedāvā atbalstītās kopas ietvaros, atstāj divus godīgus ceļus: nomainiet ierīci vai beidziet uz programmatūras vārteju, kuru kontrolējat, un no turienes maršrutējiet uz VPC. Viss pārējais ir apieta risinājums, kas izgāzīsies nākamajā pārskatā.

Viena ārējā adrese vienai ierīcei

Peer ārējai adresei jāatbilst tā iekšējai adresei viens-pret-vienu. Pārslogots PAT baseins nevar darboties, jo vairāki resursdatori aiz vienas publiskas adreses atbildētājam nededz nekādu veidu tos atdalīt. Kur vairākiem resursdatoriem jādala adrese, tunelim jābeidzas vietā, kas spēj tos atšķirt.

Saglabājiet arī šo ārējo adresi stabilu. Pārvietojiet ierīci aiz cita NAT, un saikne pārtrūkst, lai gan katrs priekšlikums joprojām atbilst. Ir vērts pierakstīt, kuras vērtības ir Google un kuras jūsu: darbības laiki, kopas un viens-pret-vienu NAT ir fiksēti viņu pusē, bet priekšlikumi, selektori, maršrutēšana un BGP prioritātes ir jūsu.