PPTP bölünmüş tünelleme çalışmıyor: önce GRE yolunu düzeltin

Bir PPTP bağlantısının ayağa kalkmasını izleyin ve zor kısmın bittiğine inanmak kolaydır: istemci kimlik doğrular, bir ppp0 bağdaştırıcısı veya WAN Miniport görünür ve durum penceresi yeşile döner. Ardından iç ana makineye giden ilk istek zaman aşımına uğrar ve profil suçlanır. Uygulamada temizlenmesi gereken iki bağımsız katman vardır: TCP 1723 ve GRE taşıyan dış taşıma ile hangi hedeflerin PPP arabirimini kullandığını belirleyen iç politika. Yeşil durum yalnızca ilk katmanın anlaştığını kanıtlar; ikincisi hakkında hiçbir şey söylemez.

İstemciyi profilden kontrol soketine kadar izleyin

İstemci günlüğünü açın ve sunucuyla iletişim kurduğu noktayı bulun. PPTP önce 1723 numaralı bağlantı noktasına bir TCP bağlantısı açar ve tünel parametrelerini bu kanal üzerinden görüşür. Bu adım başarısız olursa sonrası önemli değildir ve hata genellikle sunucu adresini veya zaman aşımını belirtir.

Herhangi bir rotaya dokunmadan önce kontrol bağlantısını ağ üzerinde doğrulayın. İstemcide veya bir ayna bağlantı noktasında, tek bir bağlantı denemesi için TCP 1723 yakalayın:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Tamamlanmış bir el sıkışma ve kurulmuş bir oturum, dış kontrol kanalının çalıştığını gösterir. Hiç SYN-ACK almayan bir SYN, güvenlik duvarına, yanlış sunucu adresine veya bağlantı noktasını filtreleyen bir sağlayıcıya işaret eder. El sıkışmanın hemen ardından sıfırlama gelmesi çoğu zaman sunucunun kimlik bilgilerini veya tünel türünü reddettiği anlamına gelir.

GRE ikinci bir protokoldür, bağlantı noktası değil

PPTP, PPP yükünü genişletilmiş GRE, yani IP protokolü 47 içinde taşır ve bunun bir yönlendiricinin izleyebileceği bağlantı noktası numarası yoktur. Bu yüzden TCP 1723'e izin veren bir kural tüneli yine de veri yolu olmadan bırakabilir. Durum tutan NAT cihazları, yanıtları geri eşlemek için GRE içindeki çağrı kimliğini anlamalıdır ve çoğu bunu yapmaz. PPTP belirtimi kontrol kanalını ve GRE yükünü ayrı parçalar olarak tutar ve test planınız da öyle olmalıdır.

Aynı yakalamada 47 protokolünü izleyin, ardından çıkanla geri döneni karşılaştırın:

sudo tcpdump -ni any 'proto gre' -c 20

TCP 1723 sağlıklı kalırken yanıtsız çıkan paketler, engellenmiş GRE'nin klasik imzasıdır. Tüketici yönlendiricisinde PPTP geçişi o belirli yazılımın bir özelliğidir, bu yüzden çalışan bir otel ağı bir sonraki hakkında hiçbir şey kanıtlamaz. Yönlendirici geçiş sunmuyorsa ve bunu değiştiremiyorsanız sorun yönlendirme tablosu değil, protokol seçimidir.

Tünelin tek bir paket taşıdığını kanıtlayın

GRE akmaya başladığında PPP görüşmesi istemci arabirimine bir adres atar. Varsaymak yerine atamayı okuyun:

ip -4 addr show ppp0

Noktadan noktaya bağlantının hedefi olarak gösterilen eş adresine ping atın. Bu aşamadaki bir yanıt, kapsüllenmiş yolun uçtan uca çalıştığını ve sunucunun tünel içinde yanıt verdiğini kanıtlar. Eş yanıt veriyor ama iç ana makineler vermiyorsa dış taşıma iyidir ve arıza içeri taşınmıştır.

Bunu herhangi bir bölünmüş rota eklemeden önce yapın. Taşıma bozukken yapılan rota değişikliği ikinci bir değişken yaratır ve birincisini gizler.

Bölünmüş politikayı yazın, DNS dahil

Bölünmüş yönlendirme bir kararlar listesidir, onay kutusu değil. Tüneli geçmesi gereken her özel önek, PPP arabirimi üzerinden bir rota gerektirir ve yerel kalması gereken her önek orada bulunmamalıdır. Bir uygulama alt ağı için özel çözümleyicisine giden eşleşen rota olmadan rota oluşturmak, bozuk uygulama gibi görünen bir kesinti yaratmanın yaygın bir yoludur.

Her kategoride bir adres için çekirdeğin verdiği kararı kontrol edin:

ip route get 10.20.5.10
ip route get 203.0.113.25

İlki ppp0, ikincisi olağan ağ geçidini belirtmelidir. İkisi de aynı arabirimi belirtiyorsa politika hiç bölünmemiştir. DNS sunucusunun kendi adresini tünel listesine ekleyin, aksi halde iç ana makineler için ad çözümlemesi yerel çözümleyiciden çıkar ve yararlı hiçbir şey döndürmez.

Beş adımda tekrarlanabilir bir kontrol

Katmanları sırayla çalıştırın ve ilk başarısız olanda durun: kontrol kanalı, GRE görünürlüğü, PPP eş yanıtı, bir iç adres için bölünmüş rota ve tünel üzerinden bir uygulama isteği. Her adımın kendi komutu vardır, böylece arıza gizemli değil atfedilebilir olur.

Linux istemcisi için kompakt sürüm şöyle görünür:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Windows'ta aynı sıra route print ve istemcide gösterilen bağdaştırıcı durumu ile geçerlidir. PPTP eski bir protokoldür ve sunucu SSTP veya IKEv2 sunuyorsa, her atlamada 47 protokolünün geçmesine bağlı bir yolu ayarlamaktan çok taşınmak genellikle zamanın daha iyi kullanılmasıdır. Eski profili yeni sürüme kopyalamak yerine değiştirmenin sertifikasını ve kimlik doğrulama sözleşmesini kontrol edin.