Ana yönlendiriciye bir VPS'ye atanan statik bir IP tüneli


1

Şu anda tek bir statik IP'ye sahip bir VPS'im var. İkinci bir statik IP alsam aşağıdaki senaryo mümkün olabilir mi?

Diyelim ki, eth0: 0'daki IP A 1.2.3.4 ve eth0: 1'deki statik IP B 5.6.7.8'dir . IP A'ya giden tüm trafiği, sunucu tarafı NAT kullanmadan ev yönlendiricime yönlendirmek istiyorum. Ev yönlendiricim ve IP B arasında bir GRE tüneli (IPsec ile güvenlik altına alınmış) kurmayı düşünüyorum. IP A'daki gelen IP paketlerinin daha sonra tünelin içine aktarılması gerekiyor. Bir diyagramın bunu daha net hale ağ diyagramı getirmesi gerektiğini düşünüyorum: Genellikle bu, Siteden Siteye VPN kullanma ve VPS'de NAT kullanma durumunun açık bir örneği olabilir, ancak aslında NAT sunucu tarafını kullanmak istemiyorum . Bunun yerine, ev yönlendiricimin giden trafiğinde srcnat yapmasını ve belirli gelen trafikte dstnat yapmasını istiyorum. VPS sadece gelen ve giden IP paketlerini "geçmelidir".

Paket akışını aşağıdaki gibi hayal ediyorum:

  1. LAN 192.168.100.0/24 içindeki ana bilgisayar 8.8.8.8’e bir paket göndermek istiyor.

  2. Ana yönlendirici bunu statik IP A'ya uyarlar (1.2.3.4)

  3. paket gre1'den geçer ve VPS'ye girer

  4. VPS, paketi kaynak eth alanını değiştirmeden bırakarak eth0: 0 aracılığıyla iletir.

  5. 8.8.8.8'den gelen cevap VPS'ye IP 1.2.3.4 hedefiyle geliyor

  6. VPS paketi alır ve NAT yapmadan gre1'e koyar.

  7. ev yönlendirici paketi işler ve kurulan veya ilgili bir bağlantı olup olmadığını kontrol eder ve ilgili LAN istemcisine iletir.

Sanırım yönelticimdeki gre1 arabirimine başka bir IP ekleyebildim, yani 1.2.3.4, bu nedenle 1) bu hedef değere sahip IP paketlerini kabul eder ve 2) tünel IP yerine bu IP ile giden paketleri gönderir (10.0. 0.2)?

Kısaca, eth0: 0'a gelen tüm paketlerin gre1'de değiştirilmemiş olarak ev yönlendiricimde gelmesini istiyorum. Bu tarif edilen şekilde mümkün olabilir mi?

BTW, ek bilgi varsa, evde bir Mikrotik yönlendirici kullanıyorum.

Yardımınız için teşekkürler!


Adım 6 zor olanıdır, çünkü hedef IP bir arayüz IP'dir, bu nedenle yönlendirme kararı rota vermeyecektir. Ve NAT, başka bir yerde yapıldığı için ... Bu senaryoda, 1.2.3.4'te gelen tüm paketlerin gre tüneline zorlanması gerekir, bu yüzden çalışabilmesi için iptables shenanigan'lara ihtiyacınız olacaktır. Sunucuda NAT yapmak istemediğinizi söylüyorsunuz - bu olamaz, çünkü?
Paul

Yorumun için teşekkürler. Sunucuda NAT yapabilirdim, ancak ev yönlendiricimde yapmayı tercih ederim, çünkü a) Mikrotik yönlendiricim bana biraz daha fazla kontrol sağlar (veya en azından yapılandırmayı sadece CLI sunucu tarafını kullanmaktan daha kolay hale getirir) ve b) Sadece denemek istedim :-) iptables kullanmanın yanı sıra - belki de benim etiğimi içeren bir köprü ve örneğin L2TP üzerinden bir katman 2 bağlantısı uygulanabilir mi? Yani tüm ethernet çerçeveleri L2TP tüneline iletiliyor mu?
Alex,

Hmm, eth0: 0 ve tun0 arayüzlerini köprü mü? Veya eth0: 1? Çözmeye çalıştığınız temel şey nedir, belki başka bir yolu var mı?
Paul

Yanıtlar:


1

İlk önce, eth0 ve eth0: 1'i ayrı arayüzler olarak düşünmeyi bırakın. Dur çizim ayrı arayüzler olarak. Onlar değil. Üzerinde iki IP adresi olan bir eth0 arayüzünüz var - gerisi Linux'un ifconfig gibi eski araçlarda oynadığı bir yanılsamadır .


Bunun dışında, bu sunucu tarafında oldukça basittir.

  1. Bunu sunucunuzda yapılandırmak için , 5.6.7.8 adresini eth0'dan kaldırarak başlayın . Sunucunun bu paketlerin kendisine ait olduğunu düşünmesini ve tüketmesini istemezsiniz; saf bir yönlendirici gibi davranmasını istiyorsunuz ve yerel bir arabirime atanmış yönlendirilmiş bir adrese sahip olmak tam olarak bir yönlendiricinin ihtiyaç duymadığı şey.

    ip addr del 5.6.7.8/x dev eth0
    
  2. Şimdi, tünelin üzerindeki adres için statik bir yol ekle:

    ip route add 5.6.7.8/32 dev gre1
    
  3. İşte bu (neredeyse). Kalan tek sorun, sunucunun barındırma şirketinizin yerel ağ geçidinden gelen bu adres için ARP sorgularını yanıtlaması gerektiğidir. Bunun için proxy-ARP özelliğine ihtiyacınız var :

    ip neigh add proxy 5.6.7.8 dev eth0
    

    Bu, bir adres için proxy-ARP sağlar . sysctl net.ipv4.conf.all.proxy_arp=1Global olarak etkinleştirmek için kullanmayın ; bu, sunucunuzun yönlendirdiği her şey için proxy-ARP yanıtlarına neden olur; bu, bazı durumlarda uygun olabilir, ancak bu durumda gereksizdir.

    (Bir yan not olarak, userpace parpd veya ndppd , çekirdek tabanlı proxy-ARP / NDP'den daha kolay anlaşılabilir.)

Kaynak IP adresine bağlı olarak iki varsayılan ağ geçidi (GRE'ye karşı doğrudan rota) arasında seçim yapması gerektiğinden, istemci yönlendiricisinde daha karmaşık bir yapılandırma gerekebilir .

Neyse ki, Mikrotik RouterOS en azından IPv4 için Linux politika yönlendirme özelliğine sahiptir (ancak hala IPv6 için değil), bu nedenle yaygın Linux ip ruletalimatlarını izleyebilir ve onları 1: 1 ile RouterOS komutlarına eşleyebilirsiniz. Kısacası:

  1. GRE tüneli üzerinden farklı bir rotaya varsayılan rota ekle tablo mark (RouterOS 'yönlendirme işareti' olarak adlandırır):

    /ip route add dst-address=0.0.0.0/0 gateway=gre0 routing-mark="tunnelled"
    
  2. Bu yönlendirmeyi seçmek için ilke kuralı ekleme işaret bu kaynak adresten gelen paketler için tablo (RouterOS ...):

    /ip rule add src-address=5.6.7.8/32 table="tunnelled"
    

Bir yorum köprü oluşturuyor. Bu iki nedenden dolayı işe yaramaz.

GRE, Ethernet benzeri başlıkları taşımayan bir Layer3 tünelidir ve bu nedenle köprü yapılamaz. Linux gretap ve Mikrotik eoip gibi Layer2 varyantları var - ne yazık ki bunlar, her ikisinin de GRE tabanlı olmasına rağmen karşılıklı olarak uyumsuz.

Yorum aslında , tünelin OpenVPN (GRE, OpenVPN değil) olduğu varsayımıyla tun'dan bahseder , ancak tun ayrıca bir Layer3 arayüzüdür. Artık bir Layer2 sürümü - dokunma arayüzü var - ve Linux OpenVPN aslında onu kullanmak ve bir Layer2 VPN olacak şekilde yapılandırılabilir ... ama RouterOS OpenVPN uygulaması bu modu zaten desteklemiyor.

Eth0 Dahası, 1 değil , ayrı bir arayüz, aynı zamanda eth0 kendisi arasında köprü kurmadan köprülü edilemez. Bir macvlan sanal arayüzü eth0 ile oluşturulabilir ve sonra bir tünelle köprülenebilir mi? Emin değil. Muhtemelen değeceğinden daha fazla sorun olurdu.


1
Bunun 2 yaşında bir soru olduğunun farkındayım. Hayır, umrumda değil. Bugünlerde güncel sorulara iyi bir cevap yazamıyorsam, en azından güncel olmayan bir tane yazacağım.
Grawity
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.