L2TP/IPsec NAT-on át: mi törik meg valójában és miért

Ez az állítás, hogy a NAT megtöri az L2TP/IPsec-et, félig igaz, ezért hasznavehetetlen. A címfordítás normális, a NAT traversal éppen azért létezik, hogy túlélje, és naponta milliók kapcsolódnak router mögül. Az törik meg, ami egy adott eszmecsere adott szakasza: az IKE soha nem kap választ, a beágyazott alagutat olyan házirend dobja el, amely csak egy protokollt engedélyez, vagy a fordítási leképezés lejár, miközben az alagút tétlen. Ha tudja, melyik szakaszban van, a javítás általában egyetlen szabály vagy egy keepalive, nem új VPN-terv.

A mítosz a rossz kérdés

A hasznos kérdés nem az, hogy „megtöri-e ezt a NAT”, hanem hogy „az eszmecsere melyik része fordul, és mit tesz vele a fordító eszköz”. Az L2TP/IPsec rétegzett protokoll: az IKE tárgyal, az ESP véd, és az L2TP PPP-t szállít ezen a védelmen belül. A címfordítás minden rétegre másképp hat, és a hiba jellemzői megkülönböztethetők, ha a tárgyalási szakaszt nézi a hibaablak helyett.

Egy sikeresen böngésző router csak azt bizonyítja, hogy a TCP forrásport-fordítással működik. Semmit sem mond az UDP 500-ról, az UDP 4500-ról vagy az 50-es protokollról, és ez a telepítés éppen ettől a háromtól függ.

Szakasz 1: az IKE-nek egyáltalán választ kell kapnia

Az első eszmecsere a válaszadóhoz megy az UDP 500-on. Ha nem jön válasz, semmi más nem számít: az előre megosztott kulcs, a javaslat és a hitelesítő adatok olvasatlanul maradnak. Figyelje a kérést és a választ, ne a kliens időtúllépéséből következtessen:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

A válasz nélküli kérés általában azt jelenti, hogy egy tűzfal vagy a felettes szolgáltató eldobja a csomagot, nem azt, hogy a szerver elutasította. A javaslatot vagy tanúsítványproblémát említő értesítési hasznos terhelést tartalmazó válasz azt jelenti, hogy a csomagok megérkeztek, és a tárgyalás a tartalom miatt hiúsult meg, ami egészen más javítás.

Ha mindkét fél fordítás mögött van, a kezdeményezőnek csak a válaszadót kell elérnie, ezért a legtöbb kliensoldali telepítés az 1-es szakasztól működik. A kiszolgálóoldali hosztolás az, ahol a bejövő probléma elkezdődik, és ezért a két helyzetet soha nem szabad egyként tárgyalni.

Szakasz 2: a beágyazás megváltoztatja, mit lát a tűzfal

Az ESP IP-protokoll, nem TCP- vagy UDP-port, és a szokásos portcím-fordításnak nincs portmezője, amit átírhatna. Ezért a NAT traversal a védett hasznos terhelést az UDP 4500-ba viszi: a beágyazás olyat ad a fordító eszköznek, amit tud fordítani. Amint ez megtörténik, egy csak UDP 500-ra írt tűzfalszabály engedélyezi a tárgyalást és eldobja az alagutat, ami azt a zavaró eredményt adja, hogy a napló sikeres 1-es fázist és semmilyen forgalmat mutat.

Magát az IKE-eszmecserét is át lehet vinni az UDP 4500-ra, miután a NAT-ot felismerték, ami meglepi azokat, akik 500-at és semmi mást engedélyeztek. Engedélyezze mindkét portot mindkét irányban az útvonalon, és ne feledje, hogy az állapotkövető tűzfal csak addig tartja a folyamot, amíg forgalmat lát.

Az 50-es protokoll továbbra is számít fordítás nélküli útvonalakon, és olyan útvonalakon, ahol egy köztes doboz engedélyezésre van beállítva. Ha kizárással diagnosztizál, kapcsolja ki a hipotézist ahelyett, hogy kötegekben adna hozzá szabályokat: engedélyezze az 500-at, a 4500-at és az ESP-t, erősítse meg, hogy az alagút feljön, majd távolítsa el azt, ami szükségtelennek bizonyult. Az a szabály, amit senki nem tud megmagyarázni, olyan szabály, amit senki nem fog eltávolítani, amikor a következő kiesés okává válik. Írja be a szűkítést a változásnaplóba a javított szakasszal együtt, hogy a következő mérnök az Ön bizonyítékaiból induljon ki, ne ugyanabból az ökölszabályból.

Szakasz 3: a leképezés lejár, és az alagút meghal

A fordító eszköz állapotot tart a továbbított folyamokhoz, és ennek az állapotnak élettartama van. Az L2TP/IPsec alagút kevés forgalmat szállít, amikor senki nem használja, ezért egy tétlen alagút túlélheti a leképezését, és többé nem kap visszforgalmat. A kliens továbbra is meg van győződve arról, hogy kapcsolódik, a szerver semmit nem lát, és az első tünet általában egy alkalmazás időtúllépése, nem VPN-hiba.

A halott partner észlelése és a NAT keepalive-ok erre valók, és mindkét félnek hajlandónak kell lennie elküldeni őket. Ha a szervere fordítás mögött van, a Windows oldali követelmény egy dokumentált beállításjegyzék-érték, amely ráveszi a szervert, hogy saját kimenő csomagjaihoz UDP-beágyazást feltételezzen; enélkül a válaszadó olyan ESP-t küld, amelyet a fordító eszköz nem tud visszafordítani. Ez szerverkonfigurációs kérdés, nem klienskérdés.

A WAN-cím változása ugyanezt az eredményt adja más irányból: a leképezés új cím köré épül, és a régi biztonsági társítás olyan sorra mutat, amely már nem létezik. Az újracsatlakozási viselkedés a kliens megvalósításához tartozik, ezért a „csatlakozz újra a router újraindítása után” az egyik kliensen működik, a másikon kézi kapcsolót igényel.

A szolgáltatói szintű NAT mögötti hosztolás más probléma

Ha otthon szeretne L2TP/IPsec szervert hosztolni, és kívülről elérni, a követelmény a kéretlen bejövő elérhetőség, és ezt nem a NAT traversal biztosítja. Ha a routere előtt szolgáltatói szintű NAT van, akkor nincs olyan port, amelyet továbbíthatna, és elérhetővé válna, mert a nyilvános cím megosztott, és a leképezés csak kimenő.

Egyetlen IPsec pass-through jelölőnégyzet sem változtat ezen, és semmilyen klienskonfiguráció nem ellensúlyozza. A támogatott válaszok: egy valóban elérhető cím, egy hosztolt végpont, vagy olyan architektúra, amelyben minden résztvevő kimenő kapcsolatot létesít. Az UDP-beágyazási specifikáció megoldja a fordítási problémát a létező folyamokhoz; nem hoz létre bejövő útvonalat ott, ahol a szolgáltató nem kínál ilyet.

Tehát hasonlítsa össze a hálózatokat ahelyett, hogy tippelne. Vigye ugyanazt az eszközt és profilt egy másik engedélyezett hálózatra, és figyelje, melyik szakasz hibázik ott. Ha máshol működik, a különbség az útvonalban van, és ez a keresést a fenti három szakaszra szűkíti a teljes konfiguráció helyett.