Filial-VPN över 4G: håll identiteten stabil när IP:n flyttar

Börja vid själva filialen, på 4G-routerns WAN-statussida. Om adressen du ser ligger i operatörens privata intervall i stället för ett offentligt, kommer ingen portvidarebefordran på den burken någonsin att låta hubben ringa in, och tunneln måste byggas utåt från filialen. Den enda observationen avgör designen. Resten av arbetet är att se till att hubben känner igen filialen på något bättre än en adress som ändras varannan timme.

Var tunneln måste börja

Kontrollera adressen mot det delade adressutrymme som operatörerna använder för sin egen NAT, 100.64.0.0/10, och mot de vanliga privata intervallen. Att se en av dem på en mobil upplänk betyder oftast att NAT på operatörsnivå sitter mellan filialen och internet, och att inkommande anslutningar inte finns till något pris filialen kan betala. När WAN-adressen är offentlig men ändras har du ett annat, enklare problem.

Dynamisk DNS hjälper bara i det andra fallet. Det ger en växlande offentlig adress ett stabilt namn att ringa, och det kan inte skapa en mappning som operatören aldrig gav. Det är ändå värt att konfigurera för det offentliga fallet, eftersom det tar bort det enda manuella steget vid en omnumrering. Vad det inte får bli är svaret för en filial som operatören aldrig gjorde nåbar.

Skilj adressen du ringer från identiteten du matchar

Hubben behöver något stabilt att hittas på, en godkänd fast adress eller ett underhållet värdnamn. Filialen behöver ett stabilt sätt att kännas igen, och i IKEv2 är det identitetsnyttolasten den visar upp under autentiseringen, oberoende av källadressen som dess paket råkar bära. En sträng som @branch-a.vpn.example fungerar som den identiteten även medan den mobila adressen ändras varje timme.

Den strängen matchas mot policy, inte löses via DNS, så förvänta dig ingen uppslagning när tunneln sätts upp. Hubbens konfiguration måste namnge den förväntade identiteten uttryckligen, och med certifikatautentisering måste identiteten också stämma med vad certifikatet faktiskt hävdar.

Att acceptera vilken identitet som helst för att källadressen verkar rimlig är det felmode som ska undvikas. På en responder innebär det att acceptera vilken peer som helst, med ett identitetsjokertecken och en delad hemlighet, vilket autentiserar en sträng snarare än en enhet.

Skriv hubbsidan som en namngiven peer

I strongSwan-termer är respondersidan en anslutning med right=%any, som accepterar en peer från vilken källadress som helst, plus [email protected], som fäster vad den peeren måste uppge sig vara. Lägg till rightsubnet=10.20.0.0/16 för filialens LAN, auto=add så att anslutningen laddas utan att ringas, dpd_delay=30s för livskraft och mobike=yes så att ett adressbyte kan absorberas i stället för att behandlas som en ny peer.

Andra tillverkare uttrycker samma objekt under andra namn, oftast en dynamisk peer- eller filialkontorstyp med ett identitetsfält och ett fält för det skyddade subnätet. Fyll i båda; en generisk dynamisk kryssruta är ingen kompatibilitetsplan.

Håll filialen som initiativtagare

På filialen gäller spegelbilden: left=%defaultroute så att den lokala mobila adressen används som den är nu, [email protected] för att visa identiteten, right=hub.example.com för det stabila hubnamnet och auto=start så att tunneln kommer upp utan en människa. När den mobila länken återansluter tar filialen initiativet igen och hubben matchar samma identitet mot samma policyobjekt.

Tillåt IKE på UDP 500, NAT-genomgång på UDP 4500 och den inkapslade ESP som följer, i båda ändar. Låt dem sedan vara tillåtna: en regel som bara öppnas under kontorstid kommer att se ut som en intermittent tunnel.

Testa adressbytet, inte bara det första handslaget

Ta upp tunneln, bekräfta den och tvinga sedan filialen till en ny adress genom att slå på och av mobildata eller flygplansläge i en minut. Titta på listan över säkerhetsassociationer på hubben och kontrollera att peer-adressen ändrades medan identiteten inte gjorde det. En tunnel som bara fungerar till operatörens första omtilldelning är inte testad alls.

Kontrollera sedan de skyddade subnäten separat. En etablerad SA säger att parterna autentiserade sig; den säger inte att hubben har en väg till filialens LAN eller att filialen tar emot trafik från hubbsidan. Läs routingtabellen och brandväggspolicyn separat och skicka sedan en ping från en värd i stället för från gatewayen, eftersom gatewayen är den minst representativa enheten i varje nätverk.

En stabil identitet gör filialen till ett policyobjekt som hubben kan namnge. Det gör inte en carrier-NAT-adress nåbar, och det ger inte resten av organisationen tillgång till filialen av sig självt.