Starlink IP: NATCloud sprendimas

Santrauka Kai Starlink klientai skundžiasi “mano IP vėl pasikeitė”, matoma problema yra sukimas, bet gilesnė problema yra CGNAT. Starlink numatytoji tinklo konfigūracija padeda klientus po bendrintos NAT, taigi inbound IPv4 pasiekiamumas iš tikrųjų nėra galimas, nebent mokate už viešojo IP priedą. Klasikiniai nuotolinės prieigos šablonai — port forwarding, DDNS, IP sąrašai — susilpnėja arba visiškai sustoja. NATCloud tai išsprendžia, pakeisdama inbound priklausomybę autentifikuotu outbound tuneliu, atkuriant valdymo prieigą be viešojo IP poreikio.

Kodėl Starlink nuolat keičia mano IP?

Starlink klientai mato, kas atrodo kaip greitas IP sukimas, nes numatytoji paslauga padeda prenumeratorius po CGNAT (Carrier-Grade NAT, RFC 6598 bendrintos adreso erdvės 100.64.0.0/10). Pagal CGNAT, viešasis adresas, kurį mato išorinės paslaugos, dalijamas tarp daugelio prenumeratorių ir gali keistis pagal egreso-kaupų perskyras be to, kad kliento maršrutizatorius WAN iš tikrųjų būtų perskirstytas. Pridėkite Starlink dinaminius pajėgumus, atsparumą ir plėtimosi sprendimus, o rezultatas yra adresas, kuris atrodo, kad juda daug trumpiau nei tipinis plačiajuosčio WAN.

Skirtumas yra svarbus, nes jis keičia sprendimą. Jei vienintelė problema būtų “mano IP yra dinaminis”, DDNS būtų pakankami — įžymėkite host šabloniniu IP ir viskas baigta. Bet pagal CGNAT nėra jokio pasaulio maršruto IPv4 kliento WAN visai. DDNS įžymėkite host šabloniniu IP, kurio kliento manymu yra “jų” IP, tačiau inbound ryšiai su tuo adresu arba nepavyksta arba nusileidžia kieno nors kito sesijai. Bendrintos adreso erdvės sulaužo “vienas klientas, vienas viešasis IP” prielaidą, kurios klasikinė nuotolinės prieigos įrankis priklauso.

Kodėl tai žaloja prieigą daugiau nei tikimasi

Tradicinė nuotolinė prieiga priklauso nuo trapios grandinės: viešasis IPv4 WAN, inbound pasiekiamumas per ISP, port-forwarding taisyklė kliento maršrutizatoriuje, firewall spyglys konkrečiam įrenginiui ir dažnai IP pagrįstas pasitikėjimo modelis priimimo pusėje. Ta grandinė turi saugumo silpnybes net ir normaliame plačiajuosčio ryšyje. Starlink CGNAT atveju tai tampa operaciškai nestabilu.

Inbound prieiga pavirsta loterija: kartais adresas nukreipiamas atgal į jūsų prenumeratorių, kartais jis nukreipiamas į kitą klientą tame pačiame egreso kaupe, kartais inbound publikavimas niekada neegzistavo iš viso. Žurnalai, geolokacija, audito prielaidos ir IP sąrašai viskas sugadinami. Tai ypač skausminga technikai valdantiems kamerams, maršrutizatoriams, DVR ir šako įrenginiams, kurie niekada nebuvo skirti tapatybės pagrįstoms prieigos modeliam — jie prielaidos stabilių viešojų IP, kuriuos galėtų leisti.

Kodėl NATCloud geriau atitinka Starlink atvejį

NATCloud nėra tik dar vienas būdas pasiekti įrenginį iš interneto — jis invertuoja modelį. Vietoj to, kad paprašytumėte viešojo interneto rasti įrenginį pagal jūsų dabartinį viešąjį IPv4, NATCloud pasiūlymas ryšyje pagrįstam autentifikuotu outbound tuneliu, kuris nustatytas iš kliento vietos į debesį. Praktinis priklausomybė iš “kas dabar yra mano viešasis IP?” į “ar vieta turi outbound ryšį?” — ir outbound ryšys beveik visada yra prieinamas Starlink, net jei inbound publikavimas nėra.

Architektūra turi antros eilės naudą. Kartą prieiga nebepriklausys nuo WAN IP likdavimo, likusi veiklos modelis tampa grynesnė: stebėjimas, perspėjimai, pasiekiamumo ataskaitos, komandos pagrįstos leidimai ir atsargos tampa tos pačios kontrolės plokštumos dalimi vietoj improvizavimo aplink keičiančius adresus, ad-hoc firewall išimtis ir skaičiuoklės sąrašus. Centralizuoti leidimai, automatinė atsargos, ataskaitos ir CGNAT, dvigubos NAT ir trigubos NAT scenarijų palaikymas yra pirmaeilės savybės, o ne darbai.

Ką tai reiškia likusiems architektūrai

NATCloud centrinė prieigos dizaino pertvarkos, kaip trys gretimos nuotolimo sprendimai yra priimti.

DDNS tampa antrine, ne pirmaeile. DDNS yra naudingas, kai egzistuoja realus inbound adresas ir kartais pasikeičia. Pagal CGNAT, DDNS negali pats kurti inbound pasiekiamumą. Starlink + NATCloud architektūra yra operaciškai stipresnė nei Starlink + DDNS daugumai diegimų. DDNS vis dar turi vaidmenį ne-CGNAT vietas toje pačioje partioje, bet jis nustoja būti numatytasis atsakymas. Pamatyti DDNS-tik pagrindinę liniją, žiūrėkite mūsų Intelbras DDNS vadovą ir VPS pagrįstą MikroTik valdymo vadovą.

Viešasis IPv4 priedas tampa verslo pasirinkimu, ne taisytu. Jei konkretus darbas iš tikrųjų reikalinga klasikinio inbound IPv4 ir Starlink palaiko viešąjį IPv4 tame plane, nuimkite jį tam darbui. Gydymui kaip išimtis žinomam reikalavimui — ne kaip pagrindinė architektūra kiekvienam įrenginiui. Dauguma tų įrenginių tik reikalinga saugus valdymo prieigą, ne viešojo interneto publikavimą.

IPv6 padeda, bet nėra stebuklas. Starlink palaiko IPv6 su mechanizmais kaip SLAAC ir deleguoti priešdėliai. IPv6 gali atkurti end-to-end pasiekiamumą, kai priešdėlis yra tinkamai deleguotas ir filtruojamas, bet jis vis dar reikalinga disciplinavimas firewall politika. Daugeliui operacijų komandų, NATCloud yra paprastesnis nei pertvarkyti kiekvieną darbas aplink tiesioginį IPv6 ekspoziciją — ypač kai įrenginio partioje yra senesnis įranga su silpnu arba neatsirandančiu IPv6 palaikymu.

Dokumentacija ir nuorodos

Dvi technines fundamentalus yra po Starlink atveju: RFC 1918 apibrėžia privataus IPv4 diapazonus vidinėms tinklams, o RFC 6598 rezervuoja 100.64.0.0/10 kaip bendrą adreso erdvę, kurią naudoja CGNAT. RFC 4862 apima IPv6 SLAAC. Kartu šie dokumentai paaiškina, kodėl “internetas veikia” nėra tas pats dalykas kaip “aš turiu stabilią inbound viešą pasiekiamumą.”

Starlink savos paramos medžiagos patvirtina, kad viešasis IPv4 yra pasirinkta konfigūracija, susieta su tam tikrais paslaugų planais, o numatytasis elgesys naudoja CGNAT ir tinklas yra dinamiškas su adresais pakintais. Šių dviejų faktų derinys — CGNAT-iš-numatytojo ir dinaminio adresumo — yra tai, kas daro inbound IP pagrįstas prieigos šablonai nepatikimi.

Atlikite kitą žingsnį

Jei jūsų prieigos dizainas vis dar priklauso nuo “mano dabartinio viešojo IP”, Starlink bus toliau jausti nestabilus. Gilesnė problema nėra emocinė ir net nėra tik Starlink specifiška — jis yra architektūrinis. Numatytame Starlink modelyje, viešasis IPv4 stabilumas ir inbound pasiekiamumas nėra saugios prielaidos. NATCloud tai išsprendžia, pašalindamas viešojo IP priklausomybę iš valdymo kelio ir pakeičiant jį kontroliuojamu outbound tuneliu, kuris elgiasi daug geriau pagal CGNAT ir dinaminio adresumo.

Geriausias atsakas į Starlink IP pokyčius nėra kovoti sunkiau tuo pačiu senais prieigos metodu. Tai yra smausti tvarumą viešo IPv4 kaip jūsų prieigos strategijos akmenį.

Pradėkite savo nemokamą MKController bandomąjį