Az otthoni VPN-kiszolgáló nem érhető el: járjuk végig a NAT-láncot

A kiszolgáló válaszol a LAN-on, a porttovábbítási szabály helyesnek tűnik, és a külső kliens mégsem tud csatlakozni. Határonként kifelé haladni gyorsabb, mint negyedszer szerkeszteni a szabályt, mert minden határ a saját bizonyítékát hagyja: az útválasztó WAN-oldala, a szolgáltató fordítása és a gazdagépen futó figyelő. Kezdjük a már nyitott felügyeleti oldalon, és fejezzük be egy olyan hálózatból indított teszttel, amelyet nem vezérlünk. Minden eredményt írjunk fel menet közben, mert a sorrend maga a diagnózis, és egy megjegyzett szám nem bizonyíték. Ha csak kimenő alagútra van szükség, a fordítás nem a mi problémánk: csak a kéretlen bejövő forgalmat blokkolják.

Kezdjük az útválasztó WAN-oldalán

Jelentkezzünk be az útválasztóra, és az állapotoldalt olvassuk, ne a porttovábbítási listát. Jegyezzük fel a WAN-címet, a hozzá tartozó interfészt, és hogy a kapcsolat típusa DHCP, PPPoE vagy valami, amit a szolgáltató biztosít. Ezután hasonlítsuk össze ezt a címet azzal, amit egy külső szolgáltatás jelent, mobil adaton lévő telefonnal, hogy a megfigyelés ne ugyanazon az útválasztón menjen vissza. A két szám különböző kérdésekre válaszol, és összehasonlításuk ennek a lépésnek a teljes értelme.

A megfigyelt nyilvános címtől eltérő WAN-cím azt jelenti, hogy legalább egy fordító van az útválasztó felett. Ez még nem hiba, mert sok szolgáltató tervezésénél fogva fordít, és a szolgáltatás mégis működik. Ha a kettő megegyezik, a cím valószínűleg az útválasztóé, és a probléma a hálózatunk belsejébe került. Mindenképpen írjuk fel a párt a dátummal, mert a szolgáltatók újraosztják a címeket, és a múlt havi jegyzetekkel való összevetés értéktelen.

Lépjünk egy ugrással feljebb

Futtassunk traceroute-ot magáról az útválasztóról, és olvassuk el az első ugrásokat. Az ismétlődő nyilvános címek, a privát címmel válaszoló első ugrás vagy a megosztott 100.64.0.0/10 tartományba eső cím mind felfelé mutató fordítóra utal. RFC 6598 pontosan az ilyen telepítéshez határozza meg ezt a tartományt, ezért erős jel, nem különlegesség, ha a WAN-mezőben látjuk. Két fordító az útvonalon kevésbé nyilvánvalóvá teszi a nyomot, ezért a mintát olvassuk, ne egyetlen sort.

Egyes szolgáltatók csak az ügyfélportálon mutatják a kiosztott címet, ezért nézzünk oda, mielőtt arra jutnánk, hogy az útválasztó hazudik. Az a portálcím, amely egyezik a külső megfigyelésünkkel, miközben az útválasztó mást jelent, a felfelé lévő fordító legvilágosabb bizonyítéka. Mindkét oldalt mentsük el a változásnaplóba, mert a vita arról, ki melyik határ gazdája, két dátumozott képpel sokkal gyorsabban megy.

Erősítsük meg a figyelőt és a továbbítást

A LAN-on végzett teszt bizonyítja, hogy a szolgáltatás helyben működik, és semmit nem bizonyít a kívülről való elérhetőségről. Sok útválasztó belülről válaszol a saját továbbítási szabályára, így a hajtűteszt sikerül, miközben a külső útvonal még zárva van. Erősítsük meg, hogy a démon ahhoz a címhez és porthoz van kötve, amelyet feltételezünk, majd teszteljünk kívülről. Az alábbiak mind csak olvasásra valók.

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

Ha a külső teszt azt mutatja, hogy egyetlen csomag sem érkezik az útválasztóhoz, a kiesés feljebb történt, és egyetlen helyi szabály sem javítja meg. Ha a csomagok megérkeznek, és semmi nem válaszol, a következő határ a figyelő vagy a gazdagép tűzfala. A gazdagépen végzett csomagrögzítés eldönti, melyiket nézzük, és kevesebb időt vesz igénybe, mint a szabályok újabb köröket sejtése. Összehasonlítás közben hagyjuk a figyelőt és annak átvitelét változatlanul, különben a következő teszt más kérdésre válaszol.

A topológiát változtassuk, ne ugyanazt a szabályt

Amikor a fordító a szolgáltatóé, a megoldás egy másik útvonal, nem egy újabb továbbítás. Egy kis VPS nyilvános címmel, kimenő alagúttal az otthoni oldalról összekötve elérhető végpontot tesz a szolgáltatás elé. A szolgáltató által adott nyilvános cím egyszerűbb ott, ahol létezik, és általában olcsóbb, mint egy gépet üzemeltetni. Az IPv6 teljesen megszünteti a fordítást, feltéve, hogy az ügyfélhálózat, a DNS-rekordok és a tűzfalszabályzat mind támogatja.

Dinamikus DNS csak egy nevet frissít; nem teremt elérhetőséget, és megosztott címre irányítva a klienseket egy olyan szolgáltatói átjáróhoz küldi, amelyet más előfizetők is használnak. Ez a hiba pontosan úgy néz ki, mint egy halott kiszolgáló, ezért fontos a korábbi lépések feljegyzése. Jegyezzük fel, milyen címre oldódott a név, amikor a teszt elbukott, és tartsuk a választ a teszt eredménye mellett.

Írjuk újra a tervet az általunk vezérelt határ köré: a figyelő, az alagút és az útvonalak. A régi továbbítást csak addig hagyjuk a helyén, amíg még valami igazat ír le, mert a topológiához már nem illő szabály rosszabb, mint a szabály hiánya. Jegyezzük fel, melyik réteg blokkolt valójában, és milyen bizonyíték mutatta ezt. Különben a felügyeleti oldalt megnyitó következő ember elölről megismétli ennek a bejárásnak minden lépését.