Proč funkční VPN stále vyprší časový limit u odpovědi
Požadavek, který dorazí na privátní server, je jen polovina výměny. Jeho odpověď musí najít klienta tunelu přes zamýšlenou bránu, trasu nebo překlad.
Požadavek dorazí, server ho zapíše do logu a klient přesto hlásí vypršení časového limitu. Taková kombinace znamená, že odpověď nenašla cestu zpět, a to je jedna z mála poruch, kterou můžete potvrdit z obou konců najednou. Provádějte kontroly popořadě a zastavte se, když některá selže.
Začněte tím, kam požadavek dorazil
Než začnete zkoumat cokoli dalšího, potvrďte, že paket dorazil ke službě. Záznam v logu na straně serveru, počítadlo spojení nebo povolený odposlech na vzdáleném konci odpovídají na stejnou otázku, a jejich nepřítomnost vás vrací k tunelu, nikoli vpřed k odpovědi. To je kontrola, která odděluje problém s předáváním od problému se zpáteční cestou.
Pokud požadavek nikdy nedorazil, zastavte se zde. Tématem je tunel, směrování k privátnímu prefixu nebo přístupové pravidlo a zpáteční cesta zde ještě není podstatná. Poznamenejte si také zdrojovou adresu, kterou server viděl. Je to buď adresa z poolu, kterou klient dostal, nebo přeložená adresa, a tento rozdíl určuje, která z dalších kontrol platí.
Odpověď potřebuje trasu do poolu
Klient vzdáleného přístupu obvykle dostane adresu z poolu a privátní síť potřebuje trasu zpět do tohoto poolu. Server, jehož výchozí trasa míří na jeho vlastní bránu, předá paket této bráně, která nemá tušení, kde pool je, a odpověď tam zemře. Klient vidí vypršení, protože se nic nevrátilo, což nelze odlišit od požadavku, který nikdy neodešel.
Zkontrolujte trasu, kterou server volí pro adresu klienta, nikoli trasu, kterou používá pro svou vlastní podsíť. Tato dvě hledání mohou dát různé odpovědi a zde je podstatné to druhé. Překlad je alternativní návrh a mění to, co server vidí. Může zjednodušit zpáteční cestu a také odstraňuje původní adresu klienta z logů serveru, což ovlivňuje každé pravidlo nebo report postavený na tomto poli.
Porovnejte odposlech na serveru s odposlechem na bráně
Porovnejte, co opouští server, s tím, co dorazí na bránu. Odposlech na odchozím rozhraní serveru a odposlech na bráně tunelu odpovídají na různé poloviny otázky a mezera mezi nimi lokalizuje ztrátu.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Požadavek vygenerovaný samotnou bránou je slabou náhradou testu z klienta, protože pochází z jiné adresy a naráží na jiná pravidla. Proto úspěšný ping z brány a neúspěšný požadavek z klienta mohou platit oba současně.
Když je na cestě několik routerů, zkontrolujte každý, který potřebuje trasu do poolu. Návrh síť-síť často vyžaduje, aby byl vzdálený prefix znám na více než jednom zařízení, a brána sama musí předávat mezi tunelem a LAN; poznámky strongSwan k předávání pokrývají stránku sysctl a firewallu.
Zaznamenejte pool, prefix a odpovědnou osobu
Do poznámky patří čtyři skutečnosti: pool, který klient dostal, privátní prefix, který potřeboval, router odpovědný za odpověď a pravidlo překladu, pokud existuje. S nimi je pozdější změna brány srovnáním, nikoli vyšetřováním.
Potom otestujte znovu s běžným klientem a skutečným účtem aplikace. Rozšíření oprávnění aplikace nemůže opravit zpáteční cestu paketu a změna účtu během této diagnostiky zmate následující srovnání. Pokud návrh spoléhá na překlad, zdokumentujte to tam, kde se čtou logy serveru. Kdo v auditní stopě uvidí neznámou zdrojovou adresu, neměl by znovu objevovat mapování z tiketu.