Captive portal da farklı dns kullanan bilgisayarlarda login gelmemesi (çözüldü)
-
Dediğim gibi güvenlik politikanız bu noktada önemli. Eğer sorun olmayacağını düşünüyorsanız kullanmanızda bir sakınca yok. Ancak şahsi fikrimce kamuya açık bir ağda kullanacaksanız "nasılsa bunları kimse bilmiyor" diyerek riske girmeyin derim :) Tünelleme işlemleri basit şeyler ve pek çok insan tarafından artık biliniyor. Kullanıcı kitleniz öğrencilerden falan oluşuyorsa aklınıza gelmeyecek bir bir şeytanlığı deneyeceklerini tecrübe ile sabitleyebilirsiniz :)
Ağınız kamuya açıksa, misafirlerinizin kim olduğunu ve niyetlerini bilmiyorsanız hepsinin "kötü adam" olduğunu var saymak gerekir diye düşünüyorum :)
Saygılarımla…
pek sorması ayıp değil (ayıp olsa sormam, edepsizliğin gerek yok değil mi?) sizin bu soruna bir çözüm öneriniz var mı?
Eğer sizin için güvenlik, kullanılabilirlikten önemliyse çözüm kolay. Hali hazırda olduğu gibi herkes sizin DNS sunucunuzu girecek :) Nasıl ki siz servis sağlayıcının size verdiği ağ ayarları dışında keyfinize göre ayar yapamıyorsanız misafirlerinizde kullanamayacak…
Yok misafirlerim canlarının istediği gibi kullansın diyorsanız izin verilebilir. Hem izin vereyim hem kontrol edeyim derseniz trafiğin normal dns trafiği olup olmadığını kontrol eden snort kuralları yazmak gerekir. Çok sancılı bir süreç olacaktır :)
-
@seker'e katılıyorum.
Kendi network kullanıcılarınız için zaten "istedikleri dns sunucusunu kullanırlar" gibi bir durum sözkonusu değil.
Dışarıdan gelenleri mutlaka başka bir interface üzerinden internete bağlamakta fayda var.
En basitinden bir tane ethernet bir tane de kablosuz acces pointten geçer çözüm. -
Eğer sizin için güvenlik, kullanılabilirlikten önemliyse çözüm kolay. Hali hazırda olduğu gibi herkes sizin DNS sunucunuzu girecek :) Nasıl ki siz servis sağlayıcının size verdiği ağ ayarları dışında keyfinize göre ayar yapamıyorsanız misafirlerinizde kullanamayacak…
Yok misafirlerim canlarının istediği gibi kullansın diyorsanız izin verilebilir. Hem izin vereyim hem kontrol edeyim derseniz trafiğin normal dns trafiği olup olmadığını kontrol eden snort kuralları yazmak gerekir. Çok sancılı bir süreç olacaktır :)
@seker'e katılıyorum.
Kendi network kullanıcılarınız için zaten "istedikleri dns sunucusunu kullanırlar" gibi bir durum sözkonusu değil.
Dışarıdan gelenleri mutlaka başka bir interface üzerinden internete bağlamakta fayda var.
En basitinden bir tane ethernet bir tane de kablosuz acces pointten geçer çözüm.ben 93 den beri adanadayım. değişik amaçlar için bir çok firmaya linux çözümleri sundum. kabul edenleri gerçekleştirdim. bu sırada da gördüm ki firmalarda çalışaların basit network ayarlarını bırakın bilgisayardan haberi yok. sadece kullanması gereken programı kullanmayı biliyorlar. örneğin bir otel düşünün. hotspot ile müşterilerine internet hizmeti verecek aynı zamanda çevreden interneti koruyacak. hotspot çözümleri şimdilerde biraz daha makul denilebilecek seviyelerde, ama 5 yıl evvel iyi para idi. nix çözümleri ile hala da şuanki hotspotların yarı fiyatına yapılabilinir. bu otele 5 sene evvel gelen müşteriler farklı dns kullanıyorlarsa bunu nasıl düzelteceklerini bilmiyorlardı. şimdilerde saolsun değişik yasaklar sebebi ile herkes öğrendi. bende google ve tübitak dns adreslerini kullanıyorum, kullandırıyorum. gelgelelim bu sorunun dns çözümlemesinden kaynaklandığını asbirim söyleyene kadar çokda düşünmemiştim. hem örnek otelimize gelen müşterilerin kaçı farklı dns kullanıyor olacak ki? ama kullanan geldiğinde de ne biçim sisteminiz var? beş para etmez bilgisayarcını var derse buda herkesin canını sıkıyor.
hülasa; örnek otelimizde zaten captiveportal sadece müşterilere şifre ile kullandırılıyor çevreninde girmesi engelleniyor. diyelim ve zurnanın zırt dediği yere gelelim. diğer ticari çözümlerde bu durum nasıl acaba? onlar bunu aşmışlarsa nasıl aşmışlar? bilen var mı?
-
Eğer sizin için güvenlik, kullanılabilirlikten önemliyse çözüm kolay. Hali hazırda olduğu gibi herkes sizin DNS sunucunuzu girecek :) Nasıl ki siz servis sağlayıcının size verdiği ağ ayarları dışında keyfinize göre ayar yapamıyorsanız misafirlerinizde kullanamayacak…
Yok misafirlerim canlarının istediği gibi kullansın diyorsanız izin verilebilir. Hem izin vereyim hem kontrol edeyim derseniz trafiğin normal dns trafiği olup olmadığını kontrol eden snort kuralları yazmak gerekir. Çok sancılı bir süreç olacaktır :)
@seker'e katılıyorum.
Kendi network kullanıcılarınız için zaten "istedikleri dns sunucusunu kullanırlar" gibi bir durum sözkonusu değil.
Dışarıdan gelenleri mutlaka başka bir interface üzerinden internete bağlamakta fayda var.
En basitinden bir tane ethernet bir tane de kablosuz acces pointten geçer çözüm.ben 93 den beri adanadayım. değişik amaçlar için bir çok firmaya linux çözümleri sundum. kabul edenleri gerçekleştirdim. bu sırada da gördüm ki firmalarda çalışaların basit network ayarlarını bırakın bilgisayardan haberi yok. sadece kullanması gereken programı kullanmayı biliyorlar. örneğin bir otel düşünün. hotspot ile müşterilerine internet hizmeti verecek aynı zamanda çevreden interneti koruyacak. hotspot çözümleri şimdilerde biraz daha makul denilebilecek seviyelerde, ama 5 yıl evvel iyi para idi. nix çözümleri ile hala da şuanki hotspotların yarı fiyatına yapılabilinir. bu otele 5 sene evvel gelen müşteriler farklı dns kullanıyorlarsa bunu nasıl düzelteceklerini bilmiyorlardı. şimdilerde saolsun değişik yasaklar sebebi ile herkes öğrendi. bende google ve tübitak dns adreslerini kullanıyorum, kullandırıyorum. gelgelelim bu sorunun dns çözümlemesinden kaynaklandığını asbirim söyleyene kadar çokda düşünmemiştim. hem örnek otelimize gelen müşterilerin kaçı farklı dns kullanıyor olacak ki? ama kullanan geldiğinde de ne biçim sisteminiz var? beş para etmez bilgisayarcını var derse buda herkesin canını sıkıyor.
hülasa; örnek otelimizde zaten captiveportal sadece müşterilere şifre ile kullandırılıyor çevreninde girmesi engelleniyor. diyelim ve zurnanın zırt dediği yere gelelim. diğer ticari çözümlerde bu durum nasıl acaba? onlar bunu aşmışlarsa nasıl aşmışlar? bilen var mı?
İlk olarak tüm müşterilerinizin bilgisayardan anlamadığı varsayımındasınız. Genel olarak haklı olabilirsiniz ama zaten bilgisayardan anlamayan müşteri sizin için risk taşımıyor. Mesele risk taşıyan "yaramaz" kullanıcının otele gelmesi. Bu durumda tcp 53 ve udp 53'ün her yere açık olması sıkıntı çıkartır ki biz zaten güvenlik önlemlerini uslu duran kullanıcılar için değil yaramaz kullanıcılar için alıyoruz… Yaramazlık yapmak isteyecek bir kullanıcının ilk deneyeceği -hadi bilemediniz ikinci deneyeceği- bağlantı noktası 53 olacaktır...
Belirli DNS sunucularını izinli eklemenizde bir sakınca yok. Ama "any to any" şeklinde her hangi bir porta izin verirseniz bu size güvenlik açığı olarak döner... Bu ise "ürün" temelli bir sorun değildir "politika" temelli bir sorundur... pfSense veya ticari bir firewall kullanmanız sonucu değiştirmez. Milyon dolar değerinde bir firewall'u da her yerden her yere tcp/udp 53 erişimine izin ver diyerek yapılandırırsanız yine tünel kazılmasına izin verecek bir güvenlik açığı oluşturmuş olursunuz...
Neresi olduğu çok önemli olmayan, ama "önemli" bir kuruma yapılan güvenlik testinde benzer bir tcp/udp 53 portu yapılandırma hatası nedeniyle atm makinelerinin (hani şu para çekmek için kullandığımız cihazlar) olduğu ağa erişim sağlanmıştı.
Benzer şekilde Captiveportal ile Squid'i bir arada kullanıyor ve özel bir firewall kuralı yazmıyorsanız yine kullanıcıların kimlik doğrulama yapmadan internete çıkmasına neden oluyor... Yine bir güvenlik denetiminde, benzer şekilde yanlış yapılandırılan bir squid yüzünden dışarıdan iç networke sızılmıştı... :)
Daha önce de dediğim gibi bu kurallar tamamen güvenlik politkanızla alakalıdır. Güvenlik politikanız bu durumu hoş görüyorsa veya bunun bir risk olmadığını düşünüyorsanız kullanabilirsiniz. Size kullanmayın veya bunu kullanın demiyoruz. Sadece böyle bir risk olduğunun farkında olun diyoruz... Farkındaysanız ve riski kabulleniyorsanız, erişilebilirlik güvenlikten daha önemliyse (ki olabilir) kullanmanızda bir sakınca yoktur... :)
Saygılarımla...
-
İlk olarak tüm müşterilerinizin bilgisayardan anlamadığı varsayımındasınız. Genel olarak haklı olabilirsiniz ama zaten bilgisayardan anlamayan müşteri sizin için risk taşımıyor. Mesele risk taşıyan "yaramaz" kullanıcının otele gelmesi. Bu durumda tcp 53 ve udp 53'ün her yere açık olması sıkıntı çıkartır ki biz zaten güvenlik önlemlerini uslu duran kullanıcılar için değil yaramaz kullanıcılar için alıyoruz… Yaramazlık yapmak isteyecek bir kullanıcının ilk deneyeceği -hadi bilemediniz ikinci deneyeceği- bağlantı noktası 53 olacaktır...
Belirli DNS sunucularını izinli eklemenizde bir sakınca yok. Ama "any to any" şeklinde her hangi bir porta izin verirseniz bu size güvenlik açığı olarak döner... Bu ise "ürün" temelli bir sorun değildir "politika" temelli bir sorundur... pfSense veya ticari bir firewall kullanmanız sonucu değiştirmez. Milyon dolar değerinde bir firewall'u da her yerden her yere tcp/udp 53 erişimine izin ver diyerek yapılandırırsanız yine tünel kazılmasına izin verecek bir güvenlik açığı oluşturmuş olursunuz...
Neresi olduğu çok önemli olmayan, ama "önemli" bir kuruma yapılan güvenlik testinde benzer bir tcp/udp 53 portu yapılandırma hatası nedeniyle atm makinelerinin (hani şu para çekmek için kullandığımız cihazlar) olduğu ağa erişim sağlanmıştı.
Benzer şekilde Captiveportal ile Squid'i bir arada kullanıyor ve özel bir firewall kuralı yazmıyorsanız yine kullanıcıların kimlik doğrulama yapmadan internete çıkmasına neden oluyor... Yine bir güvenlik denetiminde, benzer şekilde yanlış yapılandırılan bir squid yüzünden dışarıdan iç networke sızılmıştı... :)
Daha önce de dediğim gibi bu kurallar tamamen güvenlik politkanızla alakalıdır. Güvenlik politikanız bu durumu hoş görüyorsa veya bunun bir risk olmadığını düşünüyorsanız kullanabilirsiniz. Size kullanmayın veya bunu kullanın demiyoruz. Sadece böyle bir risk olduğunun farkında olun diyoruz... Farkındaysanız ve riski kabulleniyorsanız, erişilebilirlik güvenlikten daha önemliyse (ki olabilir) kullanmanızda bir sakınca yoktur... :)
Saygılarımla...
sayın şeker kardeşim;
ben seni çok iyi anladım. durumunda farkında olduğumu sanıyordum. yazılanları okuyan herkes gibi şimdi cidden farkına vardım. geldiğimiz noktada benim merak ettiğim şu: diğer ücretli olan hotspot ürünlerde de pfsense deki gibi farklı dns yazılınca login ekranı gelmiyor mu? eğer geliyorsa dns portunu any to any açmadan nasıl çözmüş olabilirler? bu captive portal denilen sistemin farklı çeşitleri varda pfsense de kullanılan dns olarak pfsense girilmezse çalışmayan tipi mi? merak ediyorum. öğrenmek istyorum. araştırdım ama kıt ingilizcem yetmedi. sorabileceğim yerlere soruyorum.
şu an için müşteri portföyümde güvenliği 1. dereccede önemseyen kimse yok. daha çok erişilebilirlik tercih ediliyor. bende bu şekilde yöneliyorum. hepsi bu. anladığım kadarı ile yaptığımız modifikasyon ciddi bir güvenlik açığı oluştrabileceği için bu kadar üstünde durdunuz. güvenliği 1. derecede gözetenleri uyarmak için çok da iyi yaptınız. herkes adına teşekkür ederim.
ama işte merak. diğer hotspot cihazlarda pfsense deki bu durum nasıl? ne kullanıyorlarda hallediyorlar farklı dns kullanma işini?
herkese kolay gele,
Barış. -
Merhabalar,
Çoğu yerde MikroTik kullanıyorum.
Mikrotikte mantık nasıl işliyor bilmiyorum ama
bağlanan cihazın(bilgisayarın) ip adresi, ağ maskesi, ağ geçidi ve dns adresi ne olursa olsun login ekranı geliyor ve login olunca internete girişi sağlıyor.
Ama nasıl olduğunu anlamış edilim. Sonuçta mikrotik 'in içindeki yazılım da bir çeşit *nix türevi.
Saygılar,
-
ama işte merak. diğer hotspot cihazlarda pfsense deki bu durum nasıl? ne kullanıyorlarda hallediyorlar farklı dns kullanma işini?
herkese kolay gele,
Barış.Diğerleri nasıl hallediyor konusuna vakıf değilim ancak pfSense de nasıl işlediğini anlatabilirim… pfSense captiveportal "layer 3" (detaylar için OSI Referans modeline bakınız) seviyesinde, yani tcp/ip seviyesinde işlem yapıyor ve başlamış olan TCP/IP oturumunun (detaylar için RFC793'ü okuyabilirsiniz) arasına giriyor. Bu nedenle bir istemcinin karşılama ekranı görebilmesi için öncelikle bir tcp/ip oturumu başlatması gerekiyor. Bunun içinde öncelikle IP adresi, ağ geçidi, DNS sunucusu almış olması ve DNS sunucuna ulaşabiliyor olması gerekiyor...
Siz web tarayıcınıza web adresi yazdığınızda, TCP/IP oturumunun başlaması için öncelikle yazdığınız alan adının IP adresine çevilirlmesi (detaylar için RFC1034) gerekiyor. Yazdığınız alan adı IP adresine çevirildikten sonra bilgisayarınız ilgili IP adresine bağlantı kurmaya çalşır. Eğer bu noktada ağ geçidiniz captiveportal çalıştıran bir pfSense ise karşınıza meşhur karşılama ekranımız gelir ve kimlik doğrulama yapmanızı ister... Kullanıcı adı ve parolanızı doğru yazdığınızda sizin IP/MAC adresiniz için TCP/IP seviyesindeki her şey yasak kuralını kaldırır ve siz internete erşim kazanırsınız...
Şimdi bu senaryoda biraz geriye gidelim... Web tarayıcısına adresi yazdığımızda eğer DNS sorgusuna cevap alıp yazdığımız adresin IP karşılığınu bulamazsak TCP/IP oturumu başlatılmaz. TCP/IP oturumu başlamadığı için pfSense'in araya girebileceği bir durum ortaya çıkmaz. Çünkü web tarayıcınız ben adresi çözemedim der ve olduğu yerde kalır. Hiç bir yere gitmeye çalışmaz.. Hiç bir yere gitmeyen bir tarayıcıyı farklı bir yere yönlendiremezsiniz... :)
DNS yanlış yada erişilemez olduğunda karşınıza çıkan sorunun nedeni budur. Bu yüzden karşılama ekranı gösterebilmek için DNS erişilebilri olmalıdır ve pfSense gateway konumunda bulunmalıdır... Bu yüzden siz kullanıcının girdiği DNS
@MuratRaci:
Mikrotikte mantık nasıl işliyor bilmiyorum ama
bağlanan cihazın(bilgisayarın) ip adresi, ağ maskesi, ağ geçidi ve dns adresi ne olursa olsun login ekranı geliyor ve login olunca internete girişi sağlıyor.
Ama nasıl olduğunu anlamış edilim. Sonuçta mikrotik 'in içindeki yazılım da bir çeşit *nix türevi.
Saygılar,
Mikrotik nasıl çalışıyor bende bilmiyorum. Eğer dediğiniz gibi ise DNS protokolü kafadan izinli geliyor olabilir veya şu an bilmediğim başka bir yöntem kullanıyor olabilirler. IP adresi, ağ maskesi ne olursa olsun dediğinize göre büyük olasılıkla "Layer 2" seviyesinde işlem yapıyor olabilir varsayımını çıkartıyorum… Uygun bir cihaz ve yeterli zamanı bulursak biraz kurcalar ne yaptığını anlamaya çalışabiliriz...
Aklınıza gelen tüm ağ cihazlarının (router, modem ya da her neyse işte) , android, blackberry ve iphone gibi telefonların, ipod, ipad, mac gibi cihazların, akıllı resim çerçevelerinin ve hatta kısmen de olsa windows işletim sisteminin içinde de Unix türevleri çalışıyor :) Özetle "Bize Her Yer Unix" :)
Saygılarımla...
-
Teşekkürler,
:)
ama işte merak. diğer hotspot cihazlarda pfsense deki bu durum nasıl? ne kullanıyorlarda hallediyorlar farklı dns kullanma işini?
herkese kolay gele,
Barış.Diğerleri nasıl hallediyor konusuna vakıf değilim ancak pfSense de nasıl işlediğini anlatabilirim… pfSense captiveportal "layer 3" (detaylar için OSI Referans modeline bakınız) seviyesinde, yani tcp/ip seviyesinde işlem yapıyor ve başlamış olan TCP/IP oturumunun (detaylar için RFC793'ü okuyabilirsiniz) arasına giriyor. Bu nedenle bir istemcinin karşılama ekranı görebilmesi için öncelikle bir tcp/ip oturumu başlatması gerekiyor. Bunun içinde öncelikle IP adresi, ağ geçidi, DNS sunucusu almış olması ve DNS sunucuna ulaşabiliyor olması gerekiyor...
Siz web tarayıcınıza web adresi yazdığınızda, TCP/IP oturumunun başlaması için öncelikle yazdığınız alan adının IP adresine çevilirlmesi (detaylar için RFC1034) gerekiyor. Yazdığınız alan adı IP adresine çevirildikten sonra bilgisayarınız ilgili IP adresine bağlantı kurmaya çalşır. Eğer bu noktada ağ geçidiniz captiveportal çalıştıran bir pfSense ise karşınıza meşhur karşılama ekranımız gelir ve kimlik doğrulama yapmanızı ister... Kullanıcı adı ve parolanızı doğru yazdığınızda sizin IP/MAC adresiniz için TCP/IP seviyesindeki her şey yasak kuralını kaldırır ve siz internete erşim kazanırsınız...
Şimdi bu senaryoda biraz geriye gidelim... Web tarayıcısına adresi yazdığımızda eğer DNS sorgusuna cevap alıp yazdığımız adresin IP karşılığınu bulamazsak TCP/IP oturumu başlatılmaz. TCP/IP oturumu başlamadığı için pfSense'in araya girebileceği bir durum ortaya çıkmaz. Çünkü web tarayıcınız ben adresi çözemedim der ve olduğu yerde kalır. Hiç bir yere gitmeye çalışmaz.. Hiç bir yere gitmeyen bir tarayıcıyı farklı bir yere yönlendiremezsiniz... :)
DNS yanlış yada erişilemez olduğunda karşınıza çıkan sorunun nedeni budur. Bu yüzden karşılama ekranı gösterebilmek için DNS erişilebilri olmalıdır ve pfSense gateway konumunda bulunmalıdır... Bu yüzden siz kullanıcının girdiği DNS
@MuratRaci:
Mikrotikte mantık nasıl işliyor bilmiyorum ama
bağlanan cihazın(bilgisayarın) ip adresi, ağ maskesi, ağ geçidi ve dns adresi ne olursa olsun login ekranı geliyor ve login olunca internete girişi sağlıyor.
Ama nasıl olduğunu anlamış edilim. Sonuçta mikrotik 'in içindeki yazılım da bir çeşit *nix türevi.
Saygılar,
Mikrotik nasıl çalışıyor bende bilmiyorum. Eğer dediğiniz gibi ise DNS protokolü kafadan izinli geliyor olabilir veya şu an bilmediğim başka bir yöntem kullanıyor olabilirler. IP adresi, ağ maskesi ne olursa olsun dediğinize göre büyük olasılıkla "Layer 2" seviyesinde işlem yapıyor olabilir varsayımını çıkartıyorum… Uygun bir cihaz ve yeterli zamanı bulursak biraz kurcalar ne yaptığını anlamaya çalışabiliriz...
Aklınıza gelen tüm ağ cihazlarının (router, modem ya da her neyse işte) , android, blackberry ve iphone gibi telefonların, ipod, ipad, mac gibi cihazların, akıllı resim çerçevelerinin ve hatta kısmen de olsa windows işletim sisteminin içinde de Unix türevleri çalışıyor :) Özetle "Bize Her Yer Unix" :)
Saygılarımla...
-
port 53 tunnel acigini kapatmak icin soyle bir yontem deneyebilirsiniz.
1- herhangi bir interface istediginiz bir vlan olusturun.
2- bu vlan icin static ip tanimlamasi yapin.
3- ardindan nat -> port forward yardimi ile dns yonlendirmesi yapmak her interface icin bir kural olusturacagiz.
a- interface secin (orn. LAN)
b- source icin networf girin veya secin.(orn. LAN subet)
c- destination any secin
d- port olarak DNS (53) secin
e- redirect ip icin ayarlamis oldugunuz vlan in static ipsini yazin
f- redirect port icin DNS (53) secin ve kaydedin
dns yonlendirmesi yapmak istediginiz her interface icin tekrarlayin redirect ip ve port ayni olacak sekilde.yardimci olmasi icin resimleri ekliyorum.
butun diger alanlari oldugu gibi birakin.
bunlari yaptiktan sonra captive portal da 53 portuna surekli izin verebilirsiniz. artik sadece sizin general setup da ayarladiginiz dnslere sorgu yapilacak. isterseniz dns forwarder dan domain engelleme dahi yapabilirsiniz.
 -
selam asbirim.
bu yazdıkların 53 nolu portu dışarıya direk açmadan yapılıyor değil mi? birde denediğini ve herhangi bir sorunla karşılaşmadığınıı varsayıyorum.
port 53 tunnel acigini kapatmak icin soyle bir yontem deneyebilirsiniz.
1- herhangi bir interface istediginiz bir vlan olusturun.
2- bu vlan icin static ip tanimlamasi yapin.
3- ardindan nat -> port forward yardimi ile dns yonlendirmesi yapmak her interface icin bir kural olusturacagiz.
a- interface secin (orn. LAN)
b- source icin networf girin veya secin.(orn. LAN subet)
c- destination any secin
d- port olarak DNS (53) secin
e- redirect ip icin ayarlamis oldugunuz vlan in static ipsini yazin
f- redirect port icin DNS (53) secin ve kaydedin
dns yonlendirmesi yapmak istediginiz her interface icin tekrarlayin redirect ip ve port ayni olacak sekilde.yardimci olmasi icin resimleri ekliyorum.
butun diger alanlari oldugu gibi birakin.
bunlari yaptiktan sonra captive portal da 53 portuna surekli izin verebilirsiniz. artik sadece sizin general setup da ayarladiginiz dnslere sorgu yapilacak. isterseniz dns forwarder dan domain engelleme dahi yapabilirsiniz.
-
hayır daha once bahsettigim yontemdeki gibi 53 portunu ipfw den actiginizi varsayıiyorum. ama 53 portunu natladigimizdan aslinda disariya degil sizin acmis oldugunuz sanal interface e yonleniyor ve pfsense cevap veriyor. bu durumda port tunnel gibi bir acik soz konusu olmuyor. test amacli denedigim tum sistemlerde nslookup sonuclarindan ve states tablosundan calistigini gozlemledim. ornek olarak dns forwarder da bir entry girip nat yonlendirmesini yaptiktan sonra
nslookup - 8.8.8.8 veya baska bir dns e girdiginiz entry sorguladiginizda pfsense de ki entry nin ip gelecektir. bu da demektir ki 53 portu aslina verilen ip e degil nat yontemi ile sorguyu gene pfsense e yapmaktadir.selam asbirim.
bu yazdıkların 53 nolu portu dışarıya direk açmadan yapılıyor değil mi? birde denediğini ve herhangi bir sorunla karşılaşmadığınıı varsayıyorum.
-
Ellerine sağlık kardeş.
hayır daha once bahsettigim yontemdeki gibi 53 portunu ipfw den actiginizi varsayıiyorum. ama 53 portunu natladigimizdan aslinda disariya degil sizin acmis oldugunuz sanal interface e yonleniyor ve pfsense cevap veriyor. bu durumda port tunnel gibi bir acik soz konusu olmuyor. test amacli denedigim tum sistemlerde nslookup sonuclarindan ve states tablosundan calistigini gozlemledim. ornek olarak dns forwarder da bir entry girip nat yonlendirmesini yaptiktan sonra
nslookup - 8.8.8.8 veya baska bir dns e girdiginiz entry sorguladiginizda pfsense de ki entry nin ip gelecektir. bu da demektir ki 53 portu aslina verilen ip e degil nat yontemi ile sorguyu gene pfsense e yapmaktadir. -
arkadaşlar bunu nasıl çözdünüz?
ben sizin yukarıda vermiş olduğunuz ve benimde aşağıda adres yazdığım yere winscp ile girdim sonra oradaki 559.ncu satırda bulunanları sizin yukarıda verdiklerinizle notepad++ ile değiştirdim amma velakin elle dns verilmiş olan makinaları yine cp karşılamadı.
adres:
/etc/inc/captiveportal.inc
yazdıklarım
#dns pass
add 65529 allow udp from any to any dst-port 53 keep-state
add 65530 allow tcp from any to any dst-port 53 keep-stateredirect non-authenticated clients to captive portal
add 65531 set 1 fwd 127.0.0.1,8000 tcp from any to any in
let the responses from the captive portal web server back out
add 65532 set 1 pass tcp from any to any out
block everything else
add 65533 set 1 deny all from any to any
pass everything else on layer2
add 65534 set 1 pass all from any to any layer2
çözüm olarak ne yapmamız lazım? pfsense 2.1 kullanıyorum.teşekkürler.
reboot edince düzeldi :)
-
port 53 tunnel acigini kapatmak icin soyle bir yontem deneyebilirsiniz.
1- herhangi bir interface istediginiz bir vlan olusturun.
2- bu vlan icin static ip tanimlamasi yapin.
3- ardindan nat -> port forward yardimi ile dns yonlendirmesi yapmak her interface icin bir kural olusturacagiz.
a- interface secin (orn. LAN)
b- source icin networf girin veya secin.(orn. LAN subet)
c- destination any secin
d- port olarak DNS (53) secin
e- redirect ip icin ayarlamis oldugunuz vlan in static ipsini yazin
f- redirect port icin DNS (53) secin ve kaydedin
dns yonlendirmesi yapmak istediginiz her interface icin tekrarlayin redirect ip ve port ayni olacak sekilde.yardimci olmasi icin resimleri ekliyorum.
butun diger alanlari oldugu gibi birakin.
bunlari yaptiktan sonra captive portal da 53 portuna surekli izin verebilirsiniz. artik sadece sizin general setup da ayarladiginiz dnslere sorgu yapilacak. isterseniz dns forwarder dan domain engelleme dahi yapabilirsiniz.
Bu çözüm aynı bizim abonelerimize güvenli internet verirken kullanıdğımız forwarding mode çözümü. mantık doğru. teşekkürler @asbirim
-
Kusura bakmazsanız bir sey sorucam captive portal altında allowed ip adrese girdigimizde
ip adres -description -bandwit up down diye yerler var dns adreslerini burda nereye girmemiz lazım tek tek
-
Yeni sürümde çalışıyor mu bu paylaşılan yöntem? Deneyen var mı?
-
standart bir yönlendirme kuralı olduğundan, çalışması lazım.
-
standart bir yönlendirme kuralı olduğundan, çalışması lazım.
Peki ben niye yapamıyorum? Şu an bunu yeni sürümde deneyip çalıştırabilen var mı?
-
bu uda hortlatayım bari. 2.4.5 de /etc/inc/captiveportal.inc dosyası baya değişmiş. bu yeni yapıda nasıl eklenir bu kurallar şimdi?
-
ihtiyacı olana yeni sürümde eklenmesi gekeren kod parçası:
$cprules .= "# Rules to allow DNS queries to external servers from unauthenticated users\n"; $cprules .= captiveportal_create_ipfw_rule("add", $rulenum, "allow udp from any to any 53 out"); $cprules .= captiveportal_create_ipfw_rule("add", $rulenum, "allow tcp from any to any 53 out"); $cprules .= captiveportal_create_ipfw_rule("add", $rulenum, "allow udp from any to any 53 in keep-state"); $cprules .= captiveportal_create_ipfw_rule("add", $rulenum, "allow tcp from any to any 53 in keep-state");peki nereye eklenecek? tabiiki aşağıdaki kodun hemen üstüne:
$cprules .= "# redirect non-authenticated clients to captive portal\n"; $cprules .= captiveportal_create_ipfw_rule("add", $rulenum, "fwd 127.0.0.1,{$listenporthttp} tcp from any to any dst-port 80 in");herkese iyi eğlenceler...
