Docker'da PPTP kimlik doğrular ama trafik taşımaz

İstemci kimlik doğrular, PPP bir adres üzerinde anlaşır ve sonra hiçbir şey hareket etmez. Ping başarısız olur, tarayıcı başarısız olur ve konteyner her zaman bağlı görünür. Bu örüntü bir yönlendirme tablosu sorunu değildir, çünkü yönlendirme sorunları genellikle denetim bağlantısını da bozar. Bu, yükün yoludur ve PPTP'de yük, az önce başarılı olan protokolden farklı bir protokoldür.

En çok zaman kazandıran sırayla beş kontrol.

Kontrol 1: denetim kanalını yükten ayırın

PPTP, TCP 1723 üzerinden kimlik doğrular ve ardından PPP yükünü GRE, IP protokolü 47 içinde taşır. GRE ne TCP ne UDP'dir, bu yüzden denetim bağlantı noktasını ileten her kural onun hakkında hiçbir şey söylemez. 1723'ü geçiren bir NAT veya güvenlik duvarı 47 protokolünü şikayet etmeden düşürebilir ve oturum başarı gibi görünen bir şekilde yarım kurulmuş kalır.

Oturum açma çalışıyorsa ve hiçbir paket geri dönmüyorsa, önce GRE varsayın ve sonra bunu kanıtlayın.

Kontrol 2: yardımcıyı ana makine çekirdeğinde doğrulayın

Bağlantı izleme, bir yardımcı olmadan TCP denetim bağlantısını bir GRE akışına bağlayamaz. Modül nf_conntrack_pptp'dir, ana makinenin çekirdeğinde yaşar ve konteyner imajı içinde yüklenmesi hiçbir şey kazandırmaz çünkü modüller tüm ana makine için geçerlidir. Docker ana makinesindeki lsmod | grep nf_conntrack_pptp kontrolün kendisidir. Yoksa, modprobe nf_conntrack_pptp onu çalışan çekirdek için yükler ve sonraki açılış hakkında hiçbir şey söylemez, bu yüzden ana makine yapılandırmasına da ekleyin.

Yeniden başlatmada kaybolan modül gelecek ay aynı bilet olur.

Kontrol 3: onu devre dışı bırakan çekirdek ilkesini okuyun

Modül mevcut olsa bile, 4.7'den itibaren çekirdekler net.netfilter.nf_conntrack_helper değerini varsayılan olarak 0 yapar, bu da her protokol için otomatik yardımcı atamasını kapatır. Bu varsayılan, doğru kurulmuş bir modülün neden hâlâ hiçbir şey yapmadığının nedenidir: kod orada ve politika onu kullanmamayı söylüyor. sysctl net.netfilter.nf_conntrack_helper geçerli değeri bildirir ve çalışma zamanında 1'e ayarlamak yardımcıyı yeniden kullanılabilir kılar. Tasarım izin veriyorsa değeri ana makinenin sysctl yapılandırmasıyla kalıcı hale getirin.

Otomatik atama, trafiğin örtük olarak beklentiler oluşturmasına izin verir ve varsayılanın değişmesinin nedeni tam da budur. Bunu güvenilen ana makineyle sınırlayın veya yardımcıyı hedefleyen açık bir kural kullanın.

Kontrol 4: konteyner yoluna ayrı bakın

Yüklenmiş bir yardımcı rota oluşturmaz. Konteynerin PPTP sunucusuna bir yola ihtiyacı vardır ve ana makinedeki yönlendirme GRE'ye her iki yönde izin vermelidir: iptables -L FORWARD -v -n 47 protokolünün kabul edilip edilmediğini ve sayaçların hareket edip etmediğini gösterir. Docker'ın masquerade kuralları TCP ve UDP'yi çevirir, 47 protokolünü değil, bu yüzden köprülü bir konteyner açık bir forward kabulüne ve bazı ana makinelerde kendi çeviri kuralına ihtiyaç duyabilir. Konteynerin imajının beklediği PPP aygıt desteğine sahip olduğunu da doğrulayın.

Kuralın metnini değil sayaçları okuyun. Var olan ve hiçbir şeyle eşleşmeyen kural süslemedir.

Kontrol 5: GRE'nin izlendiğini kanıtlayın, sonra PPTP'ye karar verin

İstemci çalışırken izleme tablosunu okuyun. Kurulmuş bir PPTP denetim girdisi ve ilgili bir GRE girdisi, yardımcının akışları bağladığı ve kalan arızanın başka bir yerde olduğu anlamına gelir. GRE girdisi olmayan bir denetim girdisi, yükün düşürüldüğü veya izlenmediği anlamına gelir, bu da sizi 2 ve 3 numaralı kontrollere geri götürür.

PPTP'nin kendisi eskidir ve MS-CHAPv2 zayıftır. Sunucu ayrıca L2TP/IPsec, IKEv2 veya WireGuard sunuyorsa, bunlardan birine geçmek bu sorun sınıfının tamamını ortadan kaldırır.

PPTP'nin kalması gereken yerlerde, istemciyi konteyner içinde değil ana makinede çalıştırmak bir NAT ve filtreleme katmanını ortadan kaldırır, bu da çoğu zaman daha ucuz karardır.