Klient stále znovu zkouší, log se zastaví před dokončením handshake a server nezaznamená vůbec nic. Tento vzorec odvádí pozornost od přihlašovacích údajů k cestě: něco mezi oběma konci odmítá přenášet protokol, který tunel potřebuje. Určete, kde se pakety zastaví, dřív než se dotknete kterékoli z obou konfigurací, protože filtrovaný protokol a špatné heslo dávají ve většině klientů stejnou vlídnou chybu. Testy jsou seřazeny podle nákladů, nejlevnější první.

Dokažte, kde se provoz zastaví

Snímejte současně na výstupním rozhraní klienta a na serveru. Porovnejte, co odešlo, s tím, co dorazilo, a poznamenejte, ve kterém směru se rozdíl objeví.

Nic na serveru znamená, že provoz zahazuje cesta nebo první NAT, zatímco příchody bez odpovědí ukazují na firewall na serveru nebo na neexistující zpětnou trasu. Router, který často ukončuje tunely, obvykle nevede užitečný log, takže se záznamem stane snímek. Zapište cílový port a číslo protokolu, protože obě selhání vypadají v dialogu klienta stejně.

PPTP umírá bez protokolu 47

PPTP přenáší řízení po TCP 1723 a svá data uvnitř GRE, což je IP protokol 47, nikoli číslo portu. Přesměrování samotného 1723 přinese klasický výsledek: spojení se autentizuje a pak ztichne, protože pro protokol nesoucí užitečné zatížení neexistuje pravidlo. Klient to nedokáže rozeznat od odmítnutého hesla, a proto musí snímek přijít před úpravami konfigurace.

Průchod funguje v opačném směru než příchozí přesměrování a firmware dost často používá jeden štítek pro obojí, aby zmátl všechny. Na linuxovém klientovi může místní firewall zahodit GRE dávno předtím, než router vůbec zasáhne, takže protokol 47 potřebuje vlastní pravidlo a pomocník conntrack musí být načtený. ufw v Ubuntu drží tato pravidla v souboru before, protože běžná allow pravidla nedokážou vyjádřit číslo protokolu. Potom firewall znovu načtěte, místo abyste restartovali stroj.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP a IPsec za dvěma NAT

L2TP uvnitř IPsec potřebuje UDP 500 pro výměnu klíčů, UDP 4500 při zjištění NAT a ESP jako protokol 50. Každé z nich se filtruje nezávisle, takže pravidlo povolující jedno nic nedokazuje o zbývajících dvou. Dva routery v sérii převádějí každý paket dvakrát a koncové body se už neshodnou na tom, co bylo vyjednáno.

Přemostěte vnější modem, nebo vypněte NAT na vnitřním routeru, aby se veřejná adresa dostala k zařízení, které tunel ukončuje. Kde není možné ani jedno, musí se tunel iniciovat zevnitř hranice dvojitého NAT, ne tam ukončovat.

Sítě operátorů a sdílení adres

WAN adresa v rozsahu 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 nebo 100.64.0.0/10 znamená, že router nemá veřejnou adresu a žádné příchozí přesměrování z internetu se k němu nedostane. NAT na úrovni operátora navíc filtruje protokoly, které nečeká, a GRE je na mobilních linkách častou obětí. Porovnejte WAN adresu na samotném routeru, ne adresu, kterou uvádí vyhledávací stránka pro klienta za ním.

Provoz stejného routeru na drátové lince oddělí zjištění o operátorovi od chyby v konfiguraci jediným testem. Kde operátor protokol odmítá, zbývají možnosti jiný transport na 443 nebo tunel iniciovaný zevnitř.

Přečtěte si seznam posluchačů, než zavřete porty

Znepokojivý sken portů je často jen sada funkcí, která se dodává zapnutá. Zinventarizujte posluchače, přiřaďte každý socket k funkci a pak funkci vypněte místo blokování portu, aby se oba pohledy nerozešly.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

Výchozí nastavení SoftEther je dobrý příklad: TCP 443, 992 a 5555, přičemž funkce L2TP/IPsec a DNS tunelu přidávají vlastní sockety. Vypnutí těchto funkcí posluchače odstraní, místo aby je skrylo, a test z vnějšího hostitele vám řekne, zda operátor port vůbec propustí. Posluchač, který odpovídá lokálně, může být přesto uzavřen výš, takže porovnejte vlastní WAN adresu routeru s tím, co hlásí vnější služba.

Související články