Tre adressbeslut innan du sätter IoT-sensorer bakom en VPN
Tre adresser fyller tre roller: den publika hubben, den autentiserade platspartnern och sensorns privata adress. Planera var och en innan du tilldelar något publikt.
Tre adresser trasslar ihop sig i varje IoT-över-VPN-plan, och de är inte samma sorts beslut. En är hur en fjärroperatör hittar tunnelns ändpunkt, en är hur platsen bevisar att den är platsen, och en är var sensorns tjänst faktiskt lyssnar. Svara i den ordningen och designen faller mestadels ut av sig själv. Svara som en enda fråga och du slutar med att tilldela publika adresser till enheter som aldrig behövde någon. En sensor bakom en utgående platstunnel är nåbar för en behörig operatör utan någon inkommande regel som pekar på sensorn.
Börja med vem som initierar
Vem som ringer avgör nästan allt därefter. När platsen ringer till en hubb behöver platsen ingen inkommande nåbarhet, och hubben behöver ett namn eller en adress som platsen kan lösa upp. Det enda valet tar bort större delen av debatten om statisk publik adressering innan den börjar.
De tre rollerna separeras sedan rent, och tabellen nedan är den kortaste formen av beslutet.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
Varje rad har en annan ägare, och det är den egentliga poängen. Hubben tillhör den som driver VPN-tjänsten, platspartnern nätverksteamet, och sensorns adress den som äger enheten.
Hubbadressen är uppstart, inte en destination
Ett namn som löser upp till en underhållen publik adress räcker för hubben. En DNS-post kan följa ändpunkten när den flyttar, utan att redigera varje platskonfiguration för hand. Vad DNS inte gör är att skapa nåbarhet eller uppdatera en klient som cachar det gamla svaret, och det är separata problem med separata lösningar.
Om du kör plats-till-plats-tunnlar utan hubb gäller samma logik i en annan form: ena sidan behöver en nåbar ändpunkt, eller båda sidorna ringer en tredje part. Någon måste fortfarande äga den adressen och dess förnyelser.
Platspartnern är en identitet med ett prefix fäst vid sig
Partnern är först en identitet och sedan ett prefix. I WireGuard-termer håller partnern ett nyckelpar och hubbens AllowedIPs-post binder den nyckeln till platsens prefix. I IKEv2-termer identifierar ett certifikat eller en fördelad nyckel platsen, och dess trafikväljare säger vad den får bära. Att ändra bara ena halvan bryter arrangemanget, och därför får en adressändring aldrig behandlas som en identitetsändring.
Håll ägandet av nyckeln eller certifikatet hos platsen i stället för hos hubboperatören, så att ett byte av leverantör inte blir ett byte av identitet.
Prefixet är den del folk glömmer att planera. Hubben måste koppla sensorns subnät till rätt partner, och operatörens klient behöver en rutt dit; en rutt som bara finns på klienten skickar trafik in i en tunnel som tyst tappar den. Skriv prefixet i platsposten bredvid nyckelfingret, så att en utbytt gateway inte kan dyka upp med en annan täckning utan att någon märker det.
Sensorns adress tillhör applikationen
En privat adress från platsens plan räcker, och det den behöver är stabilitet snarare än publik nåbarhet: en DHCP-reservation, en statisk tilldelning eller ett namn i platsens egen zon. Om enheten inte kan numreras om är översättning på platsens gateway ett legitimt svar så länge översättningen är dokumenterad och returtrafiken följer den.
En vana till som är värd att behålla: klistra aldrig in hubbens publika adress i ett nästa-hopp-fält på sensorns värd. VPN:en installerar sin egen väg, och ett vanligt Ethernet-grannskap mot en publik ändpunkt är en fiktion som ger övertygande utseende konfiguration.
Svar är den halva som hoppas över. Enheten måste skicka sitt svar tillbaka mot tunneln, antingen via en rutt till operatörens klient eller via samma gateway som översatte begäran. En sensor med fel standardgateway accepterar begäran och svarar ut i ingenting, och anteckningarna om vidarebefordran förklarar varför ankomst och svarsroutning är två krav och inte ett.
Bestäm, och skriv sedan gränsen
Skriv ner åtkomstgränsen innan någon ansluter. Begränsa gatewayen till IoT-segmentet och till de specifika tjänster operatören behöver, eftersom en fungerande rutt har en tendens att bli allmän åtkomst av misstag. Håll övervakning endast för läsning och konfigurationsbefogenhet som separata roller med separata identiteter, och namnge personen som tar bort åtkomst när kontraktet löper ut.
Godkännande tillhör nätägaren, och att befinna sig i en DMZ är inte en åtkomstpolicy.
Testet efter utrullning är tråkigt och avgörande: en begäran inom det tillåtna prefixet som lyckas, en räknare som ökar på gatewayen, och ett medvetet försök utanför prefixet som misslyckas.