Starlink Změny IP: Oprava NATCloud

Shrnutí Když se zákazníci Starlinku stěžují, že se jejich IP “znovu změnila,” je viditelný problém rotace, ale hlubší problém je CGNAT. Výchozí síť Starlinku umisťuje zákazníky za sdíleným NAT, takže příchozí dostupnost IPv4 není ve skutečnosti dostupná, pokud nezaplatíte doplněk veřejné IP. Klasické vzory vzdáleného přístupu - přesměrování portů, DDNS, seznamy IP adres - se degradují nebo zcela přestanou fungovat. NATCloud řeší tuto situaci nahrazením závislosti příchozího toku ověřeným odchozím tunelem, který obnovuje přístup správy bez nutnosti veřejné IP.

Proč Starlink stále mění moji IP?

Zákazníci Starlinku vidí, co vypadá jako rychlá rotace IP, protože výchozí služba umisťuje odběratele za CGNAT (Carrier-Grade NAT, RFC 6598 sdílený adresní prostor na 100.64.0.0/10). Pod CGNAT je veřejná adresa viditelná pro externí služby sdílena mezi mnoha odběrateli a může se změnit při přiřazování odchozího fondu bez toho, aby se WAN zákaznického routeru skutečně renumeroval. Přidejte dynamickou kapacitu Starlinku, rozhodnutí o odolnosti a expanzi a výsledkem je adresa, která se zdá posunovat na časové stupnici mnohem kratší než typický broadband WAN.

Rozlišování je důležité, protože mění řešení. Pokud by jediným problémem byla “moje IP je dynamická,” DDNS by byl dostačující - udržujte název hostitele namapovaný na aktuální IP a hotovo. Ale pod CGNAT neexistuje vůbec žádná globálně směrovatelná IPv4 na zákaznickém WAN. DDNS rozlišuje název hostitele na cokoli, co zákazník považuje za “svoji” IP, ale příchozí připojení na tuto adresu buď zcela selžou, nebo skončí v sezení někoho jiného. Sdílený adresní prostor porušuje předpoklad “jeden zákazník, jedna veřejná IP”, na kterém závisí klasická sada nástrojů pro vzdálený přístup.

Proč to více škodí přístupu, než si lidé myslí

Tradiční vzdálený přístup závisí na křehkém řetězci: veřejná IPv4 na WAN, příchozí dosažitelnost přes ISP, pravidlo přesměrování portů na zákaznickém routeru, otvor v bráně firewall na konkrétní zařízení a často na modelu důvěry založeném na IP na straně cíle. Tento řetězec má bezpečnostní slabiny i na normálním broadbandu. Na Starlinku CGNAT se stává operačně nestabilní.

Příchozí přístup se změní v loterii: někdy se adresa směruje zpět k vašemu odběrateli, někdy se směruje k jinému zákazníkovi ve stejném odchozím fondu, někdy vůbec neexistuje příchozí publikování. Protokoly, zeměpisná poloha, předpoklady auditu a seznamy IP adres se všechny degradují. To je zvláště bolestivé pro techniky spravující kamery, routery, DVR, webová rozhraní a zařízení poboček, která nikdy nebyla navržena pro modely přístupu založené na identitě - předpokládala stabilní veřejnou IP, kterou by mohla zařadit na seznam.

Proč se NATCloud lépe hodí na případ Starlinku

NATCloud není jen jiný způsob, jak dosáhnout zařízení z internetu - invertuje model. Místo toho, abyste prosili veřejný internet, aby našel zařízení podle své aktuální veřejné IPv4, NATCloud udržuje vztah zakotven v ověřeném odchozím tunelu etablovaném ze zákaznické lokality do cloudu. Praktická závislost se posunuje od “jaká je moje veřejná IP právě teď?” na “má lokalita odchozí připojení?” - a odchozí připojení je na Starlinku téměř vždy dostupné, i když příchozí publikování není.

Architektura má užitek druhého řádu. Jakmile přístup již nezávisí na tom, že WAN IP zůstane na místě, zbytek operačního modelu se vyčistí: monitorování, výstrahy, hlášení dostupnosti, oprávnění na základě týmu a inventář se stávají součástí stejné roviny řízení místo improvizace kolem měnících se adres, ad-hoc výjimek v bráně firewall a seznamů na tabulkovém kalkulátoru. Centralizovaná oprávnění, automatická inventarizace, hlášení a podpora scénářů CGNAT, dvojitého NAT a trojitého NAT jsou funkce první třídy místo obejití.

Co to znamená pro zbytek architektury

Návrh přístupu soustředěného kolem NATCloud změní tři přilehlá rozhodnutí.

DDNS se stává druhořadý, ne primární. DDNS je užitečný, když existuje skutečná příchozí adresa a příležitostně se změní. Pod CGNAT nemůže DDNS vytvořit příchozí dosažitelnost sám. Architektura Starlink + NATCloud je operačně silnější než Starlink + DDNS pro většinu nasazení. DDNS má stále roli pro lokality bez CGNAT v téže flotile, ale prestane být výchozí odpověď. Pokud chcete vidět pouze DDNS baseline, podívejte se na náš průvodce Intelbras DDNS a průvodce správou MikroTik přes VPS.

Doplněk veřejné IPv4 se stává obchodním rozhodnutím, ne opravou. Pokud konkrétní úloha skutečně potřebuje klasickou příchozí IPv4 a Starlink ji podporuje na tomto plánu, vezměte si ji pro tuto úlohu. Zacházejte s ní jako s výjimkou pro známý požadavek - ne jako se základní architekturou pro každé zařízení. Většina těchto zařízení potřebuje pouze bezpečný přístup správy, ne publikování na veřejném internetu.

IPv6 pomáhá, ale není kouzelnou hůlkou. Starlink podporuje IPv6 s mechanismy jako SLAAC a delegovanými předponami. IPv6 může obnovit end-to-end dosažitelnost, když je předpona správně delegována a filtrována, ale stále vyžaduje disciplinovanou zásadu firewall. Pro mnoho operačních týmů je NATCloud jednodušší než přestavba všech pracovních postupů kolem přímé expozice IPv6 - zvláště když flotila zařízení obsahuje starší hardware se slabou nebo chybějící podporou IPv6.

Dokumentace a references

Dva technické fundamenty podpírají případ Starlinku: RFC 1918 definuje soukromé rozsahy IPv4 pro interní sítě, zatímco RFC 6598 rezervuje 100.64.0.0/10 jako sdílený adresní prostor používaný CGNAT. RFC 4862 se zabývá IPv6 SLAAC. Společně tyto dokumenty vysvětlují, proč “internet funguje” není totéž co “mám stabilní příchozí veřejnou dosažitelnost.”

Vlastní podpůrné materiály Starlinku potvrzují, že veřejná IPv4 je volitelná konfigurace vázaná na určité plány služeb, zatímco výchozí chování používá CGNAT, a že síť je dynamická s adresami podléhajícími změnám jako součást rozhodnutí o kapacitě, odolnosti a expanzi. Kombinace těchto dvou faktů - CGNAT ve výchozím stavu plus dynamické adresování - je to, co činí příchozí přístupové vzory založené na IP nespolehlivými.

Udělejte další krok

Pokud váš návrh přístupu stále závisí na “moje aktuální veřejná IP,” Starlink bude stále vypadat nestabilně. Hlubší problém není emoční, a není ani čistě specifický pro Starlink - je architektonický. Ve výchozím modelu Starlinku nejsou stabilita veřejné IPv4 a příchozí dosažitelnost bezpečné předpoklady. NATCloud řeší tuto situaci odstraněním závislosti na veřejné IP ze cesty správy a její nahrazením řízeným odchozím tunelem, který se mnohem lépe chová pod CGNAT a dynamickým adresováním.

Nejlepší odpovědí na změny IP Starlinku je newalčit silněji pro stejnou starou metodu přístupu. Je to přestat dělat stabilní veřejnou IPv4 základem vaší strategie přístupu.

Zahajte bezplatnou zkušební verzi MKController