Egy kereskedelmi internetkimeneti VPN elrejti a címedet; nem kapcsol össze a saját házaddal. Az otthoni hálózaton lévő NAS vagy nyomtató eléréséhez kell egy átjáró, amely azon a hálózaton van, és egy kliens, amely alagutat épít hozzá. Ezután a csomagnak át kell mennie öt ellenőrzésen, és bármelyikük kudarca kívülről ugyanúgy néz ki.

1. kapu: a kliensnek ki kell választania az alagutat

Ellenőrizd, hogy a cél előtag valóban az alagútba irányul-e a kliensen. Egy split-tunnel profil, amely csak a VPN saját alhálózatát küldi, a 192.168.x.x-et egyenesen a helyi interfészen küldi ki, ahol nem jut sehova. A kliens útválasztási tábláját nézd, ne a profil nevét.

Ez a leggyakoribb hiba a telefonos klienseknél, amelyek gyakran alapértelmezés szerint csak DNS-t vagy csak egy előtagot küldenek. Ha hiányzik az útvonal, a kézfogás tökéletes lehet, és az eszköz mégis elérhetetlen.

Mielőtt továbbmész, erősítsd meg, hogy a kliens pool-címe és az otthoni alhálózat nem fedi egymást.

2. kapu: az átjárónak továbbítania kell

A VPN egy gazdagépen végződik, amelynek a visszafejtett csomagot tovább kell küldenie a LAN-ra. Ehhez engedélyezett IP-továbbítás és olyan tűzfal-szabályzat kell, amely engedi a forgalmat a VPN-interfészről a LAN-interfészre. Útválasztó készüléken ez általában beépített; egy strongSwan vagy WireGuard alatt futó Linux dobozon ez két beállítás, amit az emberek elfelejtenek. Mindkettőt ellenőrizd a szolgáltatás tesztelése előtt, mert bármelyik önmagában ugyanazt az időtúllépést adja.

Tesztelj rögzítéssel a LAN-interfészen, mert az a csomag, amely soha nem jelenik meg ott, vagy eldobódott, vagy soha nem lett továbbítva.

Ez más hiba, mint egy szolgáltatás, amely elutasítja a kapcsolatot, és ez a különbség sok időt spórol. Tartsd szűken az engedélyt, a szolgáltatásra és a VPN-poolra korlátozva, ne az egész alhálózatra.

3. kapu: a válaszútvonal dönt mindenről

A cél az általa látott forráscímre válaszol, amely vagy a kliens pool-címe, vagy az átjáró, attól függően, hogy fordítasz-e. Ha a cél alapértelmezett átjárója az otthoni útválasztó, és annak nincs útvonala a VPN-poolhoz, a válasz az interneten keresztül távozik és meghal. Ez a klasszikus egyirányú kapcsolat.

Két legitim megoldás létezik: útvonal hozzáadása a poolhoz a LAN-átjárón, vagy source-NAT a VPN-átjárón, hogy a cél mindig csak az átjáró címét lássa. A második könnyebb, és elveszíti az eredeti forrásazonosságot.

Válassz egyet szándékosan, és írd le, melyiket, mert a tűzfalszabályok és a naplók ettől függenek. A strongSwan továbbítási útmutatója végigveszi a döntés Linux oldalát.

4. kapu: nevek és előtag-átfedés

A helyi felderítési nevek nem lépik át az útválasztott határt, ezért egy eszköz, amely a házon belül barátságos néven jelenik meg, az alagúton át láthatatlan lehet. Biztosíts DNS-t a privát zónához, vagy dokumentáld a címet. Bármilyen nevet használsz, annak olyasmivé kell feloldódnia, amit a távoli kliens tud útválasztani. Ezért lehet egy eszköz egyszerre elérhető cím alapján és láthatatlan név alapján.

Az átfedő előtagok a másik csapda: ha a kliens pool 192.168.1.0/24 és az otthoni hálózat is az, a kliens a célt helyinek tekinti, és soha nem küldi át az alagúton.

Számozd újra az egyik oldalt, vagy használj olyan tartományból poolt, amellyel otthon soha nem találkozol.

5. kapu: tesztelj a házon kívülről

A konyhából végzett teszt semmit sem bizonyít, mert a forgalom talán soha nem hagyja el a LAN-t. Csatlakozz mobil hotspotról vagy más hálózatról, majd járd végig a kapukat sorrendben: útvonal a kliensen, rögzítés a LAN-interfészen, a szolgáltatás válasza, a válasz rögzítése és a névfeloldás. Az első kapu, amely nem ad bizonyítékot, az a hely, ahol a munka van.

Ha a szolgáltatás válaszol, de a név nem, DNS-problémád van, nem alagútproblémád.

Tartsd a működő konfigurációt jegyzetben a pool-lal, az útvonallal és a NAT-választással, mert a következő útválasztócsere mindhármat visszaállítja.

Kapcsolódó cikkek