Konfigurera och kontrollera Dynamic DNS på Sophos Firewall

Under Network > Dynamic DNS > Add kopplar man ett värdnamn hos DDNS-leverantören till rätt WAN-interface. Om Sophos Firewall själv har den publika IPv4-adressen väljer man Use port IP. Om brandväggen har en privat WAN-adress bakom en router är NATed public IP rätt val.

Dynamic DNS uppdaterar endast DNS-posten. Det öppnar inga portar och skapar varken NAT- eller brandväggsregler. Om en intern server bakom brandväggen ska vara nåbar måste därför även stegen i Publicera en server via DNAT vara korrekt utförda.

Samma värdnamn kan också representera en dynamisk publik WAN-adress för en Sophos DNS Protection Location. Först måste den externa A-postfrågan som beskrivs nedan returnera den aktuella IPv4-adressen för WAN; därefter kontrollerar man den platsspecifika tilldelningen enligt beskrivningen i Hantera Sophos DNS Protection Locations på ett säkert sätt. Enbart DDNS-posten tilldelar ingen Filtering Policy och ändrar inte klienternas DNS-sökväg.

Konfigurera Dynamic DNS

Först behövs ett värdnamn hos leverantören, till exempel vpn.example.net, och giltiga uppdateringsuppgifter. Brandväggen måste kunna göra DNS-uppslagningar och nå internet och leverantören. Dynamic DNS fungerar därför inte i en air gap-miljö.

Öppna Network > Dynamic DNS och klicka på Add.
Ange namnet som skapats hos leverantören under Hostname, till exempel vpn.example.net. Använd den syntax för domän och underdomäner som leverantören kräver; formatet är inte detsamma hos alla leverantörer. Kontrollera även leverantörens krav på inloggningsnamn innan konfigurationen sparas.
Välj tillhörande WAN-Interface, till exempel Port2 - WAN.
Välj Use port IP eller NATed public IP under IPv4 address.
Välj Service provider.
Ange Login name och Password eller leverantörens specifika uppdateringsnyckel.
Spara med Save och kontrollera statusen.

I den aktuella SFOS-dialogrutan kan man välja DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS och Cloudflare. Sophos tidigare tjänst myfirewall.co har lagts ned. Beroende på leverantör betyder Password inte det vanliga kontolösenordet: DynDNS använder Updater Client Key, medan ZoneEdit och EasyDNS använder en Dynamic Token. DynAccess, No-IP, DNS-O-Matic, Google DDNS och Namecheap använder användarnamn och lösenord. Om en leverantör inte kräver något användarnamn anger man enligt Sophos domänen som Login name. För FreeDNS får lösenordet i SFOS vara högst 15 tecken långt; Cloudflare är undantaget och använder en e-postadress och Global API Key.

Förbered värdnamnet och uppdateringsuppgifterna i leverantörskontot före steg 6:

DynDNS: I DynDNS-kontot skapar man ett värdnamn med önskad leverantörsdomän via My Services > DynDNS Pro > Add New Hostname. Uppdateringsnyckeln finns under Account Settings > Updater Client Key. Använd Generate Key om fältet är tomt. Varning: en nygenererad nyckel ersätter de tidigare inloggningsuppgifterna för befintliga DDNS-uppdateringsklienter; även dessa måste få den nya nyckeln. I SFOS anger man DynDNS-användarnamnet som Login name och nyckeln som Password, inte kontolösenordet.
ZoneEdit: Öppna DNS i ZoneEdit-kontrollpanelen och välj skiftnyckelsikonen vid DYN RECORDS. Ange HOST och TTL, klicka på ENABLE för DYN AUTHENTICATION TOKEN, fortsätt med NEXT och bekräfta ändringarna. I SFOS används ZoneEdit-användarnamnet och den dynamiska token i stället för kontolösenordet.
EasyDNS: Öppna MANAGE > DNS SETTINGS > MODULAR EDITOR för domänen i EasyDNS-kontrollpanelen och redigera DYNAMIC RECORDS. Ange värdnamnet och TTL, skapa Dynamic Authenticated Token med ENABLE, välj NEXT och bekräfta ändringarna. Den beställda tjänsten måste stödja Dynamic DNS. Om det redan finns en A-post ska omvandlingen bara bekräftas om posten verkligen ska bli dynamisk. I SFOS används EasyDNS-användarnamnet och token i stället för kontolösenordet.
FreeDNS: Kontrollera de värdnamn som behövs under FreeDNS-underdomäner. För SFOS gäller fortfarande inloggningsuppgifterna ovan och lösenordsgränsen på 15 tecken.

Uppdateringsnycklar och token får, precis som lösenord, inte förekomma i skärmbilder eller supportärenden.

Use port IP eller NATed public IP

Use port IP: Det valda WAN-interfacet har själv den publika IPv4-adressen.
NATed public IP: WAN-interfacet har en privat adress och en router framför brandväggen utför NAT. För att fastställa den publika adressen måste brandväggen dessutom kunna nå checkip.cyberoam.com via TCP 80.

Bridge-interface stöder inte Dynamic DNS. Om WAN-interface byggs om eller ersätts bör man kontrollera beroendena via Object usage och därefter DDNS-posten. Fler begränsningar för interface beskrivs i Använd zoner och interface på rätt sätt.

Anslut Cloudflare säkert

Den integrerade Cloudflare-leverantören kräver kontots e-postadress och Global API Key. En begränsad API-token anges inte som kompatibel autentiseringsuppgift i den aktuella Sophos-dokumentationen.

Cloudflare klassar Global API Key som en äldre metod: nyckeln har samma rättigheter som användaren och åtkomst till dennes resurser. För SFOS-integrationen bör därför en separat Cloudflare-användare begränsas till endast den zon och DNS-roll som behövs. Nyckeln hör varken hemma i skärmbilder eller supportärenden. Om en Global API Key inte är tillåten enligt säkerhetspolicyn bör man i stället använda en extern uppdateringsklient med en begränsad API-token eller en annan leverantör som stöds.

För VPN och andra tjänster där klienter ansluter direkt till brandväggens publika IP-adress måste Cloudflare-posten vara inställd på DNS only. Om proxyn har aktiverats medvetet returnerar DNS-frågan i stället Cloudflares Anycast-adresser; då måste DDNS-postens ursprungs-IP-adress kontrolleras i Cloudflare-panelen.

Kontrollera DDNS-uppslagning och tjänst

SFOS kontrollerar var femte minut om den publika IP-adressen har ändrats. Efter att konfigurationen har sparats kontrollerar man kolumnerna Last updated IP, Last updated status, Last updated time och, vid ett fel, Failure reason under Network > Dynamic DNS. Last updated IP är den adress som senast skickades till leverantören; endast en extern DNS-fråga visar vilken adress som returneras publikt.

Därefter slår man upp värdnamnet utanför den egna DNS-cachen. Under Linux och macOS:

dig @1.1.1.1 vpn.example.net A +short

Under Windows:

nslookup vpn.example.net 1.1.1.1

Svaret måste motsvara den förväntade publika IPv4-adressen. Direkt efter en ändring kan en resolver fortfarande returnera den gamla adressen på grund av DNS-TTL och cache.

Slutligen testar man själva tjänsten från ett annat nätverk, till exempel via mobilnätet. Ett korrekt DNS-svar bekräftar endast namnuppslagningen, inte att tjänsten är nåbar.

Återställa en ändring

Om posten inte fungerar som förväntat kan den redigeras under Network > Dynamic DNS via Manage. Återställ då föregående interface, IP-val, leverantör och inloggningsuppgifter. Om DDNS inte längre behövs tar man bort posten och återställer önskat DNS-värde manuellt hos leverantören. Borttagningen stoppar bara framtida DDNS-uppdateringar; den tar varken bort DNAT- eller brandväggsregler och återställer inte automatiskt DNS-posten som leverantören publicerar. Kontrollera därefter det externa DNS-svaret och tjänsten igen.

Multi-WAN, HA och CGNAT

Efter en WAN- eller HA-failover ska man alltid kontrollera DDNS-statusen, det externa DNS-svaret och tjänsten.

Multi-WAN: Varje DDNS-post är bunden till ett valt interface. Man bör inte utgå från att ett enskilt värdnamn automatiskt följer den aktiva gatewayen. Planera ett unikt värdnamn per WAN för publicerade tjänster.
HA: Felsökningsloggar synkroniseras inte mellan noderna. Det fullständiga failover-testet beskrivs i Konfigurera High Availability på Sophos Firewall.
CGNAT: NATed public IP kan publicera leverantörens delade adress, men gör inte brandväggen nåbar för inkommande anslutningar. Det krävs till exempel en riktig publik IPv4-adress, en separat uppdaterad AAAA-post med lämplig IPv6-brandväggs- och tjänstekonfiguration eller en utgående tunnel- eller relälösning. Den SFOS-DDNS-funktion som beskrivs här uppdaterar endast IPv4.

Felsökning

Välj Events och System i Log Viewer och sök efter komponenten DDNS. De tekniska fältvärdena är log_type=Event, log_subtype=System och log_component=DDNS; Status, Message och Failure reason är avgörande. De senaste posterna visas också via alternativ 4 Device Console:

show logs ddc.log lines 100

För en liveanalys kan man köra följande kommando i SSH-menyn under Device Management > Advanced Shell och sedan avsluta det med Ctrl+C:

tail -f /log/ddc.log

Kommandona och kopplingen till ddc.log är dokumenterade för SFOS 22, men har inte körts mot en kundbrandvägg här. Fler loggfiler och åtkomstvägar finns i Sophos Firewall-tjänsteloggar.

Invalid Configuration or bad authorization: Kontrollera värdnamn, leverantör och inloggningsuppgifter. För Cloudflare krävs kontots e-postadress och Global API Key.
Invalid IP: Kontrollera interfacet och valet Use port IP eller NATed public IP.
DNS Error eller Connect Failed: Kontrollera DNS, Default Route samt åtkomsten till internet och leverantören. För NATed public IP ska även åtkomsten till Check-IP-tjänsten ovan kontrolleras.
Invalid Response eller Reported Abuse: Kontrollera leverantörsstatus, konto, spärrar och gränser hos leverantören.
Success, men fel IP-adress: Jämför leverantörspanelen, det valda interfacet, IP-alternativet och det externa DNS-svaret.
FQDN stämmer, men tjänsten kan inte nås: Kontrollera portvidarebefordran på routern framför brandväggen, DNAT, brandväggsregeln och den aktuella VPN- eller tjänstekonfigurationen.

Om Cloudflare-DDNS slutar fungera först efter uppgraderingen till SFOS 22.0 MR1 ska man uppdatera till SFOS 22.0 MR2 Build 546 eller senare och testa igen. Sophos åtgärdar därmed NC-180219; detaljerna finns i artikeln om SFOS 22 MR2.