Kotiverkon VPN-palvelin ei ole tavoitettavissa: käy NAT-ketju läpi

Palvelin vastaa lähiverkossa, portin edelleenohjaussääntö näyttää oikealta, eikä ulkoinen asiakas silti saa yhteyttä. Yhden rajan kerrallaan ulospäin kulkeminen on nopeampaa kuin säännön neljäs muokkaus, koska jokainen raja jättää oman todisteensa: reitittimen WAN-sivu, operaattorin käännös ja kuuntelija isännässä. Aloita hallintasivulta, joka sinulla on jo auki, ja lopeta testiin verkosta, jota et hallitse. Kirjoita jokainen tulos muistiin sitä mukaa, koska järjestys on diagnoosi eikä muistettu luku ole todiste. Jos tarvitset vain lähtevän tunnelin, käännös ei ole ongelmasi: vain pyytämätön saapuva liikenne estetään.

Aloita reitittimen WAN-sivulta

Kirjaudu reitittimeen ja lue tila­sivu sen sijaan, että lukisit porttien edelleenohjausluetteloa. Merkitse WAN-osoite, käyttöliittymä, johon se kuuluu, ja onko yhteystyypi DHCP, PPPoE vai jotain operaattorin tarjoamaa. Vertaa sitten tätä osoitetta siihen, mitä ulkoinen palvelu ilmoittaa, ja käytä puhelinta mobiilidatalla, jotta havainto ei kulje takaisin saman reitittimen kautta. Kaksi lukua vastaavat eri kysymyksiin, ja niiden vertaaminen on tämän vaiheen koko tarkoitus.

WAN-osoite, joka poikkeaa havaitusta julkisesta osoitteesta, tarkoittaa, että reitittimen yläpuolella on ainakin yksi kääntäjä. Se ei ole vielä vika, koska monet operaattorit kääntävät suunnittelun vuoksi ja palvelu toimii silti. Jos kaksi täsmäävät, osoite kuuluu todennäköisesti reitittimelle ja ongelma on siirtynyt verkkosi sisään. Kirjoita pari joka tapauksessa muistiin päivämäärän kanssa, koska operaattorit jakavat osoitteita uudelleen ja vertailu viime kuun muistiinpanoihin on arvoton.

Mene yksi hyppy ylöspäin

Aja traceroute reitittimestä itsestään ja lue ensimmäiset hypyt. Toistuvat julkiset osoitteet, ensimmäinen hyppy, joka vastaa yksityisellä osoitteella, tai osoite jaetussa alueessa 100.64.0.0/10 viittaavat kaikki ylempänä olevaan kääntäjään. RFC 6598 määrittelee juuri tuon alueen tällaista käyttöönottoa varten, ja siksi sen näkeminen WAN-kentässä on vahva merkki eikä kuriositeetti. Kaksi kääntäjää polulla tekee jäljestä vähemmän ilmeisen, joten lue kuvio äläkä yksittäistä riviä.

Jotkut operaattorit näyttävät myönnetyn osoitteen vain asiakasportaalissa, joten katso sinne ennen kuin päättelet reitittimen valehtelevan. Portaalin osoite, joka täsmää ulkoiseen havaintoosi samalla kun reititin ilmoittaa jotain muuta, on selvin todiste ylempänä olevasta kääntäjästä. Tallenna molemmat sivut muutoslokiin, koska väittely siitä, kenelle mikä raja kuuluu, sujuu paljon nopeammin kahdella päivätyllä kuvalla.

Vahvista kuuntelija ja edelleenohjaus

Lähiverkon testi todistaa palvelun toimivan paikallisesti eikä todista mitään tavoitettavuudesta ulkoa. Monet reitittimet vastaavat omaan edelleenohjaussääntöönsä sisältäpäin, joten hairpin-testi onnistuu, vaikka ulkoinen polku on yhä suljettu. Vahvista, että taustaprosessi on sidottu siihen osoitteeseen ja porttiin, jota luulet sen käyttävän, ja testaa sitten ulkoa. Kaikki alla on vain luettavaksi.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Jos ulkoinen testi näyttää, ettei reitittimelle saavu yhtään pakettia, pudotus tapahtui ylempänä eikä mikään paikallinen sääntö korjaa sitä. Jos paketit saapuvat eikä mikään vastaa, seuraava raja on kuuntelija tai isännän palomuuri. Paketin sieppaus isännässä ratkaisee, kumpaa kahdesta katsot, ja se vie vähemmän aikaa kuin uusi kierros sääntöjen arvailua. Pidä kuuntelija ja sen kuljetus muuttumattomina vertaillessasi, muuten seuraava testi vastaa eri kysymykseen.

Muuta topologiaa, älä samaa sääntöä

Kun kääntäjä kuuluu operaattorille, korjaus on eri polku eikä uusi edelleenohjaus. Pieni VPS julkisella osoitteella, kodin puolelta lähtevällä tunnelilla liitettynä, asettaa tavoitettavan päätepisteen palvelun eteen. Operaattorin tarjoama julkinen osoite on yksinkertaisempi siellä missä se on olemassa ja yleensä halvempi kuin koneen pyörittäminen. IPv6 poistaa käännöksen kokonaan, edellyttäen että asiakasverkko, DNS-tietueet ja palomuurikäytäntö kaikki tukevat sitä.

Dynaaminen DNS päivittää vain nimen; se ei luo tavoitettavuutta, ja jakamaansa osoitteeseen osoittaminen lähettää asiakkaat operaattorin yhdyskäytävään, jota muutkin tilaajat käyttävät. Se vika näyttää täsmälleen kuolleelta palvelimelta, siksi aiempien vaiheiden muistiinpano on tärkeä. Merkitse, mihin osoitteeseen nimi ratkesi testin epäonnistuessa, ja pidä vastaus testituloksen yhteydessä.

Kirjoita suunnitelma uudelleen sen rajan ympärille, jota hallitset: kuuntelija, tunneli ja reitit. Pidä vanha edelleenohjaus paikallaan vain niin kauan kuin se kuvaa vielä jotain totta, koska sääntö, joka ei enää vastaa topologiaa, on pahempi kuin ei sääntöä lainkaan. Kirjaa, mikä kerros todella esti ja mikä todiste sen näytti. Muuten seuraava hallintasivun avaaja toistaa tämän kulun jokaisen vaiheen alusta.