VPN-kliens egy LAN-kiszolgálón: miért a rossz úton távoznak a válaszok

A tünetek egyetlen mintát követnek: egy gazdagép működik, majd kliensként VPN-hez csatlakozik, és most a LAN-kliensek elérik, miközben a válaszai eltűnnek. A gazdagépen készült rögzítés azt mutatja, hogy a válaszok az alagút-eszközön keresztül távoznak a LAN-interfész helyett. Az alagúton semmi nem tört el, és a javítás egy útvonal, nem újracsatlakozás. Végezze el az alábbi négy ellenőrzést sorrendben, és álljon meg az elsőnél, amelyik megbukik.

A válasz új csomag, nem visszafordulás

Segít elengedni azt az elképzelést, hogy a válasz ugyanazon az úton tér vissza, amelyen a kérés ment. Az útválasztás csomagonként és irányonként dől el a küldő gazdagépen. Az alagúton belül 10.64.0.23 címről érkező kérés nem hoz létre visszautat; amikor a gazdagép válaszol, az a válasz új csomagként kerül összevetésre a táblával, és azon az útvonalon távozik, amelyik nyer.

Ezért okoz egy teljes alagutas kliens olyan zavarba ejtő hibát egy olyan gépen, amely LAN-t is kiszolgál. A kliens alapértelmezett útvonalat telepít, vagy azt a két fél-alapértelmezett útvonalat, amelyet egyes kliensek előnyben részesítenek, és a LAN-kliensnek szóló válasz most az alagútra illeszkedik. A szolgáltatóhoz megy, amelynek nincs oka továbbítani, a LAN-kliens pedig időtúllépést lát, pedig a gazdagép fut és helyben válaszol. A rögzítés nyilvánvalóvá teszi, az útválasztási tábla pedig megmagyarázza.

Tartson két alhálózatot a fejében, miközben a többit olvassa. Az egyik a VPN-címkészlet, ahonnan a távoli kliensek jönnek, ebben a példában 10.64.0.0/24. A másik a LAN, amelynek működnie kell, 172.16.24.0/24, útválasztójával a 172.16.24.1 címen. A hiba az, hogy a köztük lévő forgalmat az alapértelmezett útvonal dönti el.

Bizonyítsa a rögzítéssel és a lekérdezéssel

Mielőtt bármit megváltoztat, erősítse meg, melyik eszközt fogja használni a válasz. A lekérdezés gyorsabb a rögzítésnél, és pontosan arra a kérdésre válaszol, amelyre a kernel válaszolni fog a csomag felépítésekor.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Olvassa a választ két részben. Ha dev tun0 nevet ad, a gazdagép beágyazza a választ és átadja a szolgáltatónak, a LAN-kliens pedig soha nem látja. Ha dev eth0 nevet ad, de a kliens mégis időtúllépést kap, az útvonal már helyes, és a csomag később eldobódik, ami más probléma és más javítás.

Az ugyanabban a lépésben készült rögzítés eldönti azt a kételyt, amelyet a ping nem tud. A LAN-klienshez érkező visszhangválasz azt bizonyítja, hogy valamelyik út működik, nem azt, hogy melyik interfész vitte, ezért a gazdagépen magán futtassa a rögzítést, és figyelje, honnan távoznak a keretek. Az azonos alhálózaton lévő nyomtató tovább válaszol, mert közvetlen útvonala pontosabb az alagút alapértelmezett útvonalánál. Az átirányított port pontosan úgy bukik meg, mint bármely más folyam, mert az interfészt a tábla választja, nem a kapcsolat.

Telepítse a legszűkebb útvonalat, amely felülmúlja az alagutat

A prefixhossz dönt, nem a metrika, ezért a kliens-készlet útvonala a LAN-útválasztón keresztül legyőzi bármely alapértelmezett útvonalat, amelyet a VPN-kliens telepít. Metrikaműtétre nincs szükség, és az alapértelmezett útvonal maradhat pontosan ott, ahová a kliens tette.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Használjon replace-et add helyett, mert az újracsatlakozó kliens már telepítette a saját bejegyzését, és egy második add már létező útvonal hibájával bukik meg, amely engedélyproblémának látszik. Windows-gazdagépen az egyenértékű route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, ahol a -p megőrzi a bejegyzést újraindításokon át, mivel a kliens újraépítheti a táblát, amikor az alagút újra feljön. Kortárs Windows-gazdagépen a támogatott egyenértékű New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, a régebbi route parancs pedig örökölt formaként marad meg.

Egy részlet dönti el, hogy ez helyes-e vagy csak hihető: a következő ugrásnak annak az útválasztónak kell lennie, amely valóban birtokolja a kliensekhez vezető visszautat. Az útvonal olyan címre irányítása, amely maga is az alagúton keresztül érhető el, hurkot hoz létre, amely szakaszos veszteségként jelenik meg, nem tiszta hibaként. A sor véglegesítése előtt erősítse meg, hogy a következő ugrás a LAN-alhálózaton van.

Őrizze meg a választ újracsatlakozás után

A kézzel hozzáadott útvonal legjobb esetben a következő újracsatlakozásig él. Ha a kliens-készlet dinamikus, rögzítse a kiszolgáló konfigurációjában, hogy az általa irányított prefix maradjon az a prefix, amelyet a kliensek kapnak; különben a bejegyzés üres tartományra mutat, és a tünet hetekkel később, nyilvánvaló ok nélkül visszatér. Az útvonal beírása a kliens saját up-szkriptjébe a másik megbízható lehetőség, mert az a kliens táblájának újraírása után fut.

Egy állapotkövető tűzfal még legyőzheti a helyes útvonalat. Ha a rögzítés most azt mutatja, hogy a válasz eth0 interfészen távozik, és a kliens mégis időtúllépést kap, ellenőrizze, hogy a gazdagép nem dobja-e el a csomagot küldés előtt. A szigorú fordított útvonal szűrés és a net.ipv4.conf.all.rp_filter 1-re állítva eldobják azokat a csomagokat, amelyek forrása nem azon az interfészen menne vissza, amelyen érkezett, és ez pontosan az az aszimmetrikus eset, amelyet épp most hozott létre, majd javított, a conntrack állapot pedig ugyanezt a történetet mondja az átirányított portoknál.

Az utolsó ellenőrzés az, amelyet az emberek kihagynak: ismételje meg a lekérdezést, miután az alagút lement és újra feljött. Négy értéknek kell egyeznie azzal, amit felírt: a cél, a következő ugrás, az eszköz és a választott forrás. Ha bármelyik elmozdult, a kliens újraírta a táblát, és a javítás a hookjaiba tartozik, nem egy shell-előzménybe.