VPN mezi lokalitami funguje jen jedním směrem: dvě různé závady
Odpověď, která se nikdy nevrátí, a spojení, které bylo odmítnuto, jsou dvě různé závady. Porovnejte zásady, směrování a zdrojovou adresu, kterou server skutečně vidí.
Lokalita A dosáhne na B, B se nedostane na A a tunel vypadá v obou směrech v pořádku. Než se tunelu dotknete, určete, kterou závadu vlastně máte. Nové spojení zahájené na B, které je odmítnuto, a odpověď na spojení zahájené na A, která nikdy nedorazí, dávají podobné stížnosti a úplně jiné diagnózy. Jedno je problém zásad nebo trasy na cestě; druhé je problém zpětné cesty nebo stavu pro provoz, který už byl povolen.
Toto rozlišení rozhoduje, které příkazy má smysl spouštět.
Dvě závady, které vypadají stejně
V prvním případě hostitel B pošle na A SYN a nic se nevrátí. Ve druhém hostitel A úspěšně otevře relaci a odpověď na zpáteční cestě zmizí. Oba uživatelé říkají, že spojení je jednosměrné, a oba popisují paket, který zmizel, takže popis sám je nerozliší.
Zeptejte se, která strana neúspěšný pokus zahájila. Tento jediný fakt odstraní polovinu možných příčin.
Pak ověřte, že test po celou dobu používal stejné hostitele a stejnou službu. Ping z jedné strany a spojení na sdílenou složku z druhé zkoušejí dvě různé věci a diagnostika z brány může vybrat adresu tunelu, kterou žádný uživatelský provoz nepoužívá.
První případ: chybí zpětná cesta
Vzdálený server, který odpovídá přes jinou výchozí bránu, může požadavek přijmout a odpověď odeslat jinam. Stavové firewally pak asymetrickou odpověď zahodí, protože neodpovídá navázanému toku, což vypadá přesně jako směr, který nikdy nefungoval. Překlad přidává další variantu: cíl vidí přeloženou zdrojovou adresu a odpovídá na ni, takže pravidlo napsané pro původní adresu nikdy nesedí.
Ověřte adresu, kterou cíl po překladu skutečně vidí, a zpětnou trasu pro tuto adresu, ne pro původní podsíť.
Druhý případ: zásady to nikdy nepovolily
Opačný případ je jednodušší a častější, než vypadá: jedna pobočka má centrální službu využívat a nikdy do centra nezahajovat spojení. Tato asymetrie je záměrné rozhodnutí o přístupu a tunel funguje tak, jak byl navržen. Přečtěte si zásady přístupu, než změníte jakékoli nastavení tunelu. Který směr byl zamýšlen, říká dokument, ne zachytávání paketů. Zachytávání ukáže jen to, co se stalo, ne co bylo povoleno.
Pokud je obousměrné zahajování skutečně potřeba, přidejte povolení pro konkrétní službu přes podporovanou sadu pravidel platformy. Udělat všechny podsítě vzájemně důvěryhodnými kvůli opravě jedné aplikace mění úzký požadavek na široké povolení a tato výměna se málokdy zpětně reviduje.
Porovnejte stav před a po na stejných hostitelích
Sledujte oba konce stejného pokusu, ne dva oddělené pokusy. Zachytávejte na bráně hostitele, který spojení zahajuje, a na cíli, pak porovnejte, co vešlo, co vyšlo a jakou adresu vzdálená strana viděla.
tcpdump -ni any host 10.20.30.40 and port 445 conntrack -L | grep 10.20.30.40 ip route get 10.20.30.40 swanctl --list-sas
Pokud zachytávání na cíli ukazuje požadavek s neočekávanou zdrojovou adresou, odpověď je v překladu nebo směrování, ne v bezpečnostních zásadách tunelu. Pokud cíl neukazuje žádný požadavek, paket chráněnou cestu nikdy nepřešel.
Po opravě zopakujte stejný test ze stejného hostitele a potvrďte, že nesouvisející přístup je stále zamítnut. Stav tunelu “established” sám o sobě nepodporuje ani jeden z obou závěrů.