Filial-VPN over 4G: hold identiteten stabil når IP-en flytter seg

Begynn ved selve filialen, på WAN-statussiden til 4G-ruteren. Hvis adressen du ser ligger i operatørens private område i stedet for et offentlig, vil ingen portvideresending på den boksen noen gang la huben ringe inn, og tunnelen må bygges utover fra filialen. Den ene observasjonen avgjør designet. Resten av arbeidet er å sørge for at huben kjenner igjen filialen på noe bedre enn en adresse som endres hver par timer.

Hvor tunnelen må begynne

Kontroller adressen mot det delte adresseområdet operatørene bruker til sin egen NAT, 100.64.0.0/10, og mot de vanlige private områdene. Å se en av dem på en mobil opplenke betyr vanligvis at operatørnivå-NAT står mellom filialen og internett, og at innkommende tilkoblinger ikke er tilgjengelige til noen pris filialen kan betale. Når WAN-adressen er offentlig men endres, har du et annet og enklere problem.

Dynamisk DNS hjelper bare i det andre tilfellet. Det gir en skiftende offentlig adresse et stabilt navn å ringe til, og det kan ikke lage en tilordning operatøren aldri ga. Det er likevel verdt å konfigurere for det offentlige tilfellet, fordi det fjerner det ene manuelle trinnet ved omnummerering. Det det ikke må bli, er svaret for en filial operatøren aldri gjorde tilgjengelig.

Skill adressen du ringer fra identiteten du matcher

Huben trenger noe stabilt å bli funnet på, en godkjent fast adresse eller et vedlikeholdt vertsnavn. Filialen trenger en stabil måte å bli gjenkjent på, og i IKEv2 er det identitetsnyttelasten den viser fram under autentisering, uavhengig av kildeadressen pakkene tilfeldigvis bærer. En streng som @branch-a.vpn.example fungerer som den identiteten selv mens den mobile adressen endres hver time.

Den strengen matches mot policy, ikke løses via DNS, så ikke forvent et oppslag ved tunneloppsett. Hubens konfigurasjon må navngi den forventede identiteten eksplisitt, og med sertifikatautentisering må identiteten også stemme med det sertifikatet faktisk hevder.

Å akseptere enhver identitet fordi kildeadressen ser plausibel ut er feilmodusen som må unngås. På en responder betyr det å akseptere enhver peer, med et identitetsjokertegn og en delt hemmelighet, noe som autentiserer en streng snarere enn en enhet.

Skriv hubsiden som en navngitt peer

I strongSwan-termer er respondersiden en forbindelse med right=%any, som aksepterer en peer fra enhver kildeadresse, pluss [email protected], som fester hva den peeren må erklære å være. Legg til rightsubnet=10.20.0.0/16 for filialens LAN-er, auto=add slik at forbindelsen lastes uten å bli ringt, dpd_delay=30s for livlighet, og mobike=yes slik at et adressebytte kan absorberes i stedet for å behandles som en ny peer.

Andre leverandører uttrykker de samme objektene under andre navn, vanligvis en dynamisk peer- eller filialkontortype med et identitetsfelt og et beskyttet subnetfelt. Fyll ut begge; en generisk dynamisk avkrysningsboks er ikke en kompatibilitetsplan.

Hold filialen som initiativtaker

På filialen gjelder speilbildet: left=%defaultroute slik at den lokale mobile adressen brukes som den er nå, [email protected] for å vise identiteten, right=hub.example.com for det stabile hubnavnet, og auto=start slik at tunnelen kommer opp uten et menneske. Når den mobile lenken kobles til igjen, tar filialen initiativ på nytt, og huben matcher den samme identiteten mot det samme policyobjektet.

Tillat IKE på UDP 500, NAT-gjennomgang på UDP 4500 og den innkapslede ESP-en som følger, i begge ender. La dem så være tillatt: en regel som bare åpnes i arbeidstiden vil se ut som en ustabil tunnel.

Test adressebyttet, ikke bare det første håndtrykket

Ta tunnelen opp, bekreft den, og tving deretter filialen over på en ny adresse ved å slå mobildata eller flymodus av og på i ett minutt. Følg med på sikkerhetsassosiasjonslisten på huben og kontroller at peer-adressen endret seg mens identiteten ikke gjorde det. En tunnel som bare virker til operatørens første omtildeling, er ikke testet i det hele tatt.

Kontroller deretter de beskyttede subnettene separat. En etablert SA sier at partene autentiserte seg; den sier ikke at huben har en rute til filialens LAN eller at filialen godtar trafikk fra hubsiden. Les rutetabellen og brannmurpolicyen hver for seg, og send deretter en ping fra en vert i stedet for fra gatewayen, siden gatewayen er den minst representative enheten på ethvert nettverk.

En stabil identitet gjør filialen til et policyobjekt huben kan navngi. Det gjør ikke en carrier-NAT-adresse tilgjengelig, og det gir ikke resten av organisasjonen tilgang til filialen av seg selv.