sithscrl.carelink.sjunet.org (ldap://sithscrl.carelink.sjunet.org:389/cn=SITHS CA CrossBorder TEST v3, o=SITHS CA, c=se?certificateRevocationList;binary)
Borttag av information om SITHS Root CA v1 och tillägg av information om nya IP-adresser efter flytten av SITHS Certifikatutfärdare som ska ske under 2023.efter flytten av SITHS Certifikatutfärdare som ska ske under 2023.
1.31
SITHS Förvaltning
Lade till schematisk skiss över DNS-uppslag och routinlogik
Innehållsförteckning
Klicka nedan för att visa Innehållsförteckning
...
Info
Kunder med Sjunetuppkoppling ska ha tagit del av avsnittet:
Samma API som för produktion. Test hanteras genom separata kortprodukter som bara kan beställas i SITHS Admins testmiljö
...
Expandera
title
Visa Förvaltningsspecifik information om IP-adresser,portar & Protokoll per miljö
Inkludera sida
INTERNA - Nätverksinställningar för SITHS Certifikatsutfärdare
INTERNA - Nätverksinställningar för SITHS Certifikatsutfärdare
SITHS Certifikatsutfärdare via Sjunet
Ankare
kontroll_over_sjunet
kontroll_over_sjunet
Schematiska skisser för DNS-uppslag och routinglogik
Efter flytt av SITHS Certifikatutfärdare under 2023
Expandera
title
EFTER flytten gäller följande logik för DNS-uppslag och routing
Organisationens tjänster slår upp ovan funktioners DNS-värden och får SAMMA IP-adresser oavsett om man ställer sin DNS-fråga över Internet eller Sjunet
Respektive IP-adress går att nå BÅDE via Internet och Sjunet
Organisationen måste bestämma OM man vill att trafiken ska gå över Internet eller Sjunet
Observera! För organisationer med Sjunetuppkoppling - Det IP-spann som används har tidigare kommunicerats som att det ska trafikeras över Sjunet. Därav måste organisationen med största sannolikhet se till att IP-spannet 82.136.183.0/24 routas över Internet om man INTE villa att trafiken ska gå över Sjunet.
Beroende på vilket nätverk trafiken tar enligt ovan beslut måste organisationen se till att trafiken Source-NAT:as bakom en IP-adress som SITHS-tjänsten förknippar med samma nätverk. Detta för att förhindra asynkron routing.
Om trafiken går över Internet måste trafiken Source NAT:as bakom en Internet IP-adress
Om trafiken går över Sjunet måste trafiken Source NAT:as bakom en Sjunet IP-adress
Exempel på fel som kan uppstå: Organisationen skickar trafiken via Sjunet, MEN med en Source-IP som pekar på Internet. Vilket gör att SITHS försöker skicka tillbaka anropet via Internet och svaret når aldrig frågande part.
Brandväggsöppningar måste finnas i rätt brandvägg beroende på vilken väg trafiken tar enligt ovan logik för de
Från den server, klientdator etc. som vill kontrollera ett SITHS-certifikat mha. ovan funktioner kan man göra en trace route för att följa trafiken på väg mot målet
Tecken på att trafiken går över Internet
Näst sista IP-adressen är: 194.168.212.13
Tecken på att trafiken går över Sjunet
Näst sista IP-adressen är: 81.89.159.168
Åtkomst och Source-NAT
Info
Arbete pågår för att sätta upp funktioner för end-to-end tester till maskiner hos den nya driftleverantören som följer samma trafikmönster som de riktiga funktionerna.
...
Expandera
title
Visa information om Nätverksinställningar för SITHS via Sjunet innan flytten av SITHS PKI
SITHS e-id Root CA v2
För SITHS e-id kommer det inte finnas separata sökvägar för Sjunet på det sätt som det funnits för SITHS. Istället använder vi Sjunets DNS som har två ”vyer”. Om man frågar på zonen siths.se:
via sjunet så får man Sjunet IP-adresser
via internet, så får man Internet IP-adresser
En organisation som har både Sjunet och Internet och vars regionala DNS-servrar har åtkomst till båda näten kan få olika IP-adresser beroende på vilka av Sjunets DNS-servrar som svarar först. Därför behöver dessa organisationer förmodligen se över sin DNS-infrastruktur enligt nedan:
Konfigurera ert lokala nätverk enligt dokumentationen för DNS-inställningar på Sjunets sida på https://www.inera.se även för zonen siths.se och inte bara sjunet.org
Stöd för både SjunetochInternet för olika klienter i den lokala miljön
Det enklaste är att ha olika lokal DNS-hantering för de två olika näten.
Eventuellt kan man även lösa detta genom att skapa olika conditional forwards baserat på käll-ip för den klient som ställer frågan till den lokala DNS:en.
...
Expandera
title
Klicka för att visa sökvägar till spärrlistor i Produktionsmiljö
