Hvers vegna VPN-þjónn á bak við CGNAT tekur aldrei við tengingum

Beinirinn tilkynnir WAN-vistfang sem byrjar á 100.72, kraftstæða DNS-heitið leysist í annað opinbert vistfang og VPN-þjónninn á þeim beini lýkur aldrei handabandi utan frá. Póttaframsending er uppsett, þjónustan keyrir og próf úr LAN virkar enn. Ekkert í annál beinisins lítur út eins og villa. Þessi samsetning er NAT á stigi símafyrirtækis og engin eldveggjarregla getur opnað pórt á vistfangi sem ISP heldur.

Að staðfesta sameiginlega vistfangið tekur tvær mínútur og kemur í veg fyrir viku af stillingarbreytingum.

Merkin sem benda til NAT símafyrirtækisins

Berðu saman WAN-vistfangið á stöðusíðu beinisins við vistfangið sem ytri uppfletting tilkynnir. WAN-vistfang innan 100.64.0.0/10 er venjulega merkið og einkasviðin 10/8, 172.16/12 og 192.168/16 þýða það sama. Ef traceroute sýnir sama opinbera hoppið endurtekið, eða snemma hopp svarar með einkavistfangi, er annar þýðandi milli beinisins og internetsins. Sum ISP skrá aðeins úthlutað vistfang í viðskiptavinagáttinni, svo flyttu það gildi út ásamt traceroute.

Að skipta um samskiptareglur eða pórt hjálpar ekki, því vandamálið er innkomið aðgengi en ekki lokaður pórt.

Hvers vegna framsending og kraftstæð DNS geta ekki lagað það

Póttaframsendingarregla varpar pórti á WAN-tengi beinisins, en innkomið umferð nær aldrei því tengi: ISP þýðir hana fyrst og framsendir aðeins það sem eigin tafla leyfir. Að birta sameiginlega vistfangið í kraftstæðri DNS beinir biðlurum að gátt ISP sem margir áskrifendur nota, þess vegna leysist heitið en handabandið mistekst samt. Hairpin-próf takast vegna þess að beinirinn svarar eigin reglu innan frá, og UPnP hefur nákvæmlega sama blindblett.

Að stilla biðlarann upp á nýtt hjálpar ekki heldur, því bilunin verður áður en nokkur biðlarastilling er lesin.

Framsenda um VPS með skýrum leiðum

Settu opinbert vistfang framan við með því að leigja minnsta VPS sem ræður við umferðina og láttu heimabeinirinn síðan hringja út til þess. Útleiðar-UDP frá heimanetinu fer í gegnum NAT símafyrirtækisins, svo göngin byggjast innan frá og VPS verður aðgengilegi endapunkturinn. Heimahliðin verður biðlari með fast gönguvistfang, ekki þjónn.

Á VPS, bættu við biðlarasértækri skráarfærslu svo þjónninn viti hvaða jafningi á heimasviðið, og bættu við samsvarandi kjarnaleið.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

Línan iroute segir OpenVPN hvaða biðlari fær umferð fyrir heimasviðið; línan route setur það svið í kjarnatöflu VPS svo pakkar fari yfirhöfuð inn í göngin. Fyrir birtu þjónustu bætirðu við áfangastaðar-NAT-reglu sem framsendir opinbera pórtinn á 10.8.0.10 og virkjar net.ipv4.ip_forward.

Prófaðu leiðina utan frá

Staðfestu hvert hopp á opinberu hliðinni, því farsæl göng sanna ekki að þjónustan sé aðgengileg. Hlustunarstaða og pakkafang á VPS aðgreina 'ekkert kom' frá 'kom og var hent'.

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

Ef fangið sýnir pakka frá símanum en ekkert svar, er næsta stopp stilling þjónsins eða eldveggurinn. Ef fangið sýnir ekkert, er biðlarinn enn að leysa eða senda á rangt vistfang.

Valkostir sem er þess virði að verðleggja fyrst

Sérstakt IPv4-vistfang frá ISP er stysta lausnin og er venjulega lítill mánaðarkostnaður. Innfædd IPv6 fjarlægir þýðingu á báðum endum þegar VPN, biðlarakerfið og DNS-færslurnar bera það allar. Mesh-lag með undirnetsbeini innan heimanetsins nær sömu framsendingu án VPS, gegn því að vera háð samhæfingarþjónustu.

Veldu framsendinguna þegar krafan er stöðugt innkomið aðgengi og hver regla á að vera undir þinni stjórn. Veldu vistfang ISP þegar fjárhagurinn leyfir og markmiðið er einfaldlega að hætta að hugsa um það.