A telephelyek közti VPN válasza nem megy át az alagúton
Az alagutat kikerülő válasz a túloldali útválasztási döntés. Ellenőrizze a hoszttáblát, a szelektorokat és az rp_filtert, majd válasszon útvonalat vagy NAT-ot.
Egy egész délelőttöt töltöttem egy alagúttal, amely tisztán feljött és a forgalmat pontosan egy irányba vitte: a fióktelep elérte a központi fájlszervert, és minden a központból a fióktelep felé nyitott kapcsolat az első SYN-nél meghalt. Az SA-k éltek, az alagút számlálói nőttek, és a kézfogás soha nem volt a probléma. A választ olyan helyre irányították, amelyet az alagút nem fed le, és ez a döntés a túloldalé. A telephelyek közti VPN csak azokat a csomagokat viszi át, amelyeket a hoszt az átjárónak ad, és minden hoszt ezt a döntést külön hozza meg, minden irányban, a saját útválasztási táblájából.
Mindkét irány külön útválasztódik
Az IP semmit nem jegyez meg egy beszélgetés irányából. Minden csomagot küldő hoszt lefuttatja a saját leghosszabb előtag keresését, kiválaszt egy következő ugrást, és elfelejti a döntést. A kérés és a válasz két független csomag, amelyek véletlenül ugyanahhoz a kapcsolathoz tartoznak, az alagút pedig egy ugrás, amelyet bármelyikük használhat vagy nem. Semmi az IKE-cserében nem tanítja meg a távoli szervert, hogyan érje el az alhálózatát; a tárgyalás csak abban állapodik meg, mely előtagok titkosíthatók.
Ez a megegyezés a második kapu. A strongSwanon a forgalomszelektorok a leftsubnet és a rightsubnet, és az a csomag, amelynek forrása vagy célja a megtárgyalt páron kívül esik, nem titkosított, bármit is mond az útválasztási tábla. Az alagútba irányított, de a szelektorokból hiányzó előtag csendes egyirányú hiba: az útvonal helyesnek látszik, a csomag mégis nyíltan elmegy vagy eldobják, és csak a charon naplója panaszkodik.
A távoli hoszt semmit nem tud az alagútjáról
A távoli LAN-on belül a válasz egy közönséges csomag a kliense címére. A célhoszt nem lát IPsec-fejlécet, és semmi oka nincs előnyben részesíteni a VPN-átjárót; megkeresi az előtagját, nem talál az alapértelmezett útvonalánál konkrétabbat, és azt követi. Ha az alapértelmezett egy központi tűzfalra mutat, annak vagy van visszaútja az alagútba, vagy nincs. Ha nincs, csendes eldobást, ICMP unreachable-t vagy olyan választ kap, amely az internet felé néző interfészen kimegy és meghal.
Egy második interfész is elég ezt elrontani, akkor is, ha van útvonal. Egy NAS, amelynek kezelőlinkje másik VLAN-on van, egy szerver tartalék uplinkkel, egy házirend-szabály, amely egy forrástartományt egy második táblába küld: ezek bármelyike elkaphatja a választ. Linuxon a ip rule show és a ip route show table all olyan szabályokat és táblákat mutat, amelyeket az alapértelmezett lista elrejt.
A választ küldő gépen olvassa ki a döntést
Kérdezze meg a kernelt, mielőtt bármit változtat, és adja meg neki a forráscímet, mert a forrásfüggő szabályok megváltoztatják a választ.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"A kimenet megnevezi a kimenő interfészt és a következő ugrást. Ha az interfész nem a VPN-átjáró felé néző, megtalálta a hibát, és a hátralévő munka annak eldöntése, hova tartozik az útvonal. Az átjáróról indított ping itt keveset bizonyít: olyan címmel válaszol, amelyet a távoli hoszt el tud helyezni, nem a laptopja címével.
Windowson a megfelelők a Find-NetRoute -RemoteIPAddress 10.10.5.10 a döntéshez és a Get-NetRoute a táblához. Az New-NetRoute-tel hozzáadott útvonal, amely magasabb metrikát visel az alapértelmezettnél, csendesen veszít, ezért a metrikaoszlopot olvassa, ne a bejegyzést. Utána csomagokkal erősítse meg: a tcpdump -ni any "host 10.10.5.10 and tcp port 445" a távoli LAN interfészen mutatja a kérést, és ugyanaz a szűrő az alagút oldalán mutatja, jött-e vissza válasz. Látható kérés válasz nélkül azt jelenti, hogy a választ máshova irányították vagy eldobták; a rossz interfészen megjelenő válasz megadja a tettest, mielőtt bármelyik útvonalhoz hozzányúlna.
Amikor a szerver átjárója nem a VPN végpontja
Sok telephely tűzfalat tesz a szerverek és a koncentrátor közé. Az a tűzfal továbbítja a választ, tehát kell neki egy útvonal a kliens-előtagjához a VPN-átjáró felé, és továbbítási házirend mindkét irányban. Az állapottal rendelkező eszközök rontják a helyzetet: a kérés átlépte a tűzfalat egy LAN-hosztól, amelyet engedélyezett, a válasz most más irányból érkezik, és a kapcsolatkövetési bejegyzés már nem illeszkedik, ezért a csomagot érvénytelenként dobják el, nem megtagadottként. Ezért tűnik üresnek a házirendnapló, miközben a forgalom eltűnik.
Az átjárónak saját második szűrője van. A Linux fordított útvonal szűrése eldobja azokat a csomagokat, amelyek forrása nem érhető el azon az interfészen, amelyen érkeztek, és pontosan ez egy legitim aszimmetrikus visszaút alakja. a strongSwan továbbítási útmutatója éppen ezért kér net.ipv4.ip_forward-et és egy lazított net.ipv4.conf.all.rp_filter-et. Az 1 szigorú értéke bármelyik átjárón csendesen elront egy helyes útvonalat, és a nstat -az mutatja az eldobásokat, ha tudja, hova nézzen.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Irányítson vagy fordítson, majd ellenőrizze mindkét irányban
A két javítás nem egyenértékű. Az útvonal hozzáadása érintetlenül hagyja a kliens címét, így a forrásalapú szabályok, az auditnaplók és a hívót rögzítő alkalmazások tovább működnek; az ára, hogy minden döntést hozó ugrásnak kell az útvonal, ami több hely a hibára. Álcázás a távoli átjárón egy ugrásra zsugorítja a visszautat, mert a válasz most magának az átjárónak szól, és elrejti, melyik kliens mit tett.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEVálassza tudatosan: amint a kliensek az átjáró címeként jelennek meg, a forrásalapú ACL-ek már nem tudják megkülönböztetni őket, és a conntrack-nek tartania kell a leképezést, hogy a válasz visszaíródjon az alagútba. Ha a szelektorok továbbra is kizárják a kliens előtagját, a NAT semmit nem változtat, mert a kérés soha nem lépett be az alagútba.
Mielőtt javítottnak nyilvánítja, négy dolgot igazoljon sorrendben: az útvonalat a választ küldő hoszton, az útvonalat minden továbbító ugráson, a két előtagot lefedő szelektorokat, és egy rögzítést, amely a választ a várt forrással belépni mutatja az alagútba. Utána ismételje meg a tesztet a másik telephelyről. Az egyik irány átengedése félig nyitott terv, és a második irány általában más okból bukik el, mint amit éppen javított.