Bir VPN kullanıcısının tek bir yazıcıya ihtiyacı var, tüm LAN'a değil

Kural doğru görünüyor ve yazıcı hâlâ reddediyor. Ya da yazıcı çalışıyor ve aynı kullanıcı dosya sunucusuna da ulaşıyor, ki bu daha kötü. İki sonuç da genellikle aynı yerden gelir: dar kural, zaten daha geniş bir şeye izin veren bir kural kümesine eklendi. Geçerli sırayı okumak, yeni bir kural yazılmadan önce sonucu açıklar.

Belirti: dar kural hiçbir şeyi değiştirmedi

Özel bir VPN havuzu, tek bir yazıcı adresi ve TCP 631 üzerinde izin kuralı makul bir tasarımdır. Hiçbir değişiklik getirmediğinde ilk şüphe, trafiğin o kurala hiç ulaşmadığı olmalıdır. Bir kural yalnızca değerlendirme sırasında kendi konumuna ulaşan trafik hakkında karar verir. Alanları kontrol etmek kolaydır ve nadiren hatanın nedenidir.

Tersi belirtiyi gözden kaçırmak daha kolaydır. Yazdırma işi başarılı olur, bu kullanıcının asla ulaşmaması gereken bir dosya paylaşımına bağlantı da başarılı olur. Bu, daha önce bir şeyin LAN'a izin verdiği anlamına gelir.

İki belirti de yeni kuralın alanlarına değil sıralamaya işaret eder. Biri hiç eşleşmeyen bir kural, diğeri çok erken eşleşen bir kuraldır.

Trafik gerçekte hangi kural kümesine çarpıyor

pfSense kuralları arayüz başına değerlendirir ve OpenVPN'in her sunucu ve istemci örneğine uygulanan kendi sekmesi vardır. Bu kurallar belirli bir OpenVPN arayüzüne atanan kurallardan önce işlenir. Bu yüzden OpenVPN sekmesinde bırakılan geniş bir izin, arayüz sekmesi ne derse desin bu kullanıcı için de geçerlidir. Bu sırayı değişiklik kaydına kopyalayın ki inceleme GUI'yi açmadan kontrol edebilsin.

Bu yüzden yeni dar bir izin erişimi geri alamaz. Güvenlik duvarı kuralları izin ekler ve onu önceki bir eşleşmeden almaz.

Geçerli listeyi yukarıdan okuyun ve trafikle eşleşen ilk kuralda durun. O ilk eşleşme karardır ve altındaki her şey o akış için ulaşılamazdır.

İzin kuralını yazdırma işinden yazın

Yazıcıdan değil işten başlayın. Kullanıcı yazıcı adresindeki yazdırma hizmetine ihtiyaç duyar, bu yüzden kural o adresi, o protokolü ve o bağlantı noktasını adlandırır. VPN havuzu için bir takma ad ve yazıcı için bir takma ad kuralı okunur tutar.

Bir sihirbazı memnun etmek için keşif veya yönetim bağlantı noktaları ekleme dürtüsüne direnin. Tüm yazıcıyı kabul eden bir kural, yazdırma kuyruğunu kabul eden bir kuraldan farklı bir politikadır.

Yazıcının kendi kimlik doğrulamasını yerinde tutun. Ağ izni onun yerine geçmez. Kuyruk düzeyinde bir hesap, kimin neyi yazdırabileceği konusunda doğru kontroldür.

Altı değer tüm amacı taşır: eylem olarak izin, aile olarak IPv4, protokol olarak TCP, kaynak olarak havuz takma adı, hedef olarak yazıcı takma adı ve bağlantı noktası olarak 631. Bu altının ötesindeki her şey istenenden farklı bir politikadır.

İstemciye LAN izni olmadan bir yol verin

İstemcinin yazıcı adresine bir rotaya, ofis tarafının da VPN havuzuna bir yanıt yoluna ihtiyacı vardır. Tek bir /32 göndermek istemci yapılandırmasını dar tutar, bu da sorun gidermeye yardımcı olur. Bu yetkilendirme sınırı değildir, çünkü istemci kendi rotalarını ekleyebilir.

Kuyruk adla adresleniyorsa çözümleyici bağımlılığını ayrı tanımlayın. Tek bir adın çözülmesi için tüm LAN'a izin vermek, işin gerektirdiğinden çok daha büyük bir değişikliktir.

Havuza geri yönlendirme ile kaynağı çevirme arasında bilinçli seçim yapın. İkisi de çalışır ve her biri günlüklerden farklı bir şey saklar.

İşin yanı sıra reddi de test edin

VPN kullanıcısından küçük, hassas olmayan bir iş gönderin, ardından reddedilmesi gereken bir LAN kaynağını ve güvenlik duvarının kendi yönetim sayfasını deneyin. Üç test de aynı oturuma aittir, çünkü politikayı bir bütün olarak görmenin tek yolu budur. Tek başına başarılı bir yazdırma işi sınır hakkında neredeyse hiçbir şey kanıtlamaz.

Dağıtımı yalnızca yazıcı olarak adlandırmadan önce IPv6'yı ve herhangi bir başka etkin VPN yolunu gözden geçirin. Bir adres ailesinde dar olan bir kural kümesi diğerinde tamamen açık olabilir.