Dua antarmuka jaringan dan dua alamat IP pada subnet yang sama di Linux

Saya baru-baru ini mengalami situasi di mana saya membutuhkan dua alamat IP pada subnet yang sama ditugaskan untuk satu host Linux sehingga kami dapat menjalankan dua situs SSL / TLS. Pendekatan pertama saya adalah menggunakan IP aliasing, misalnya menggunakan eth0: 0, eth0: 1, dll, tetapi admin jaringan kami memiliki beberapa pengaturan yang cukup ketat untuk keamanan yang menghancurkan ide ini:

Mereka menggunakan pengintaian DHCP dan biasanya tidak mengizinkan alamat IP statis. Pengalamatan statis dilakukan dengan menggunakan entri DHCP statis, sehingga alamat MAC yang sama selalu mendapatkan penugasan IP yang sama. Fitur ini dapat dinonaktifkan per switchport jika Anda bertanya dan Anda punya alasan untuk itu (untungnya saya memiliki hubungan yang baik dengan orang-orang jaringan dan ini tidak sulit dilakukan).
Dengan pengintaian DHCP dinonaktifkan pada switchport, mereka harus memasukkan aturan pada sakelar yang mengatakan alamat MAC X diizinkan untuk memiliki alamat IP Y. Sayangnya ini memiliki efek samping dengan mengatakan bahwa alamat MAC X HANYA diizinkan untuk memiliki Alamat IP Y. Aliasing IP mensyaratkan bahwa alamat MAC X diberi dua alamat IP, jadi ini tidak berfungsi.

Mungkin ada cara mengatasi masalah ini pada konfigurasi switch, tetapi dalam upaya untuk menjaga hubungan baik dengan admin jaringan saya mencoba mencari cara lain. Memiliki dua antarmuka jaringan sepertinya langkah logis berikutnya. Untungnya sistem Linux ini adalah mesin virtual, jadi saya dapat dengan mudah menambahkan antarmuka jaringan kedua (tanpa me-reboot, saya dapat menambahkan - cukup keren). Beberapa penekanan kemudian saya memiliki dua antarmuka jaringan dan berjalan dan keduanya menarik alamat IP dari DHCP.

Tetapi kemudian masalah muncul: admin jaringan dapat melihat (pada saklar) entri ARP untuk kedua antarmuka, tetapi hanya antarmuka jaringan pertama yang saya bawa akan menanggapi ping atau segala jenis lalu lintas TCP atau UDP.

Setelah banyak menggali dan menusuk, inilah yang saya temukan. Tampaknya bekerja, tetapi tampaknya juga banyak pekerjaan untuk sesuatu yang sepertinya sederhana. Adakah ide alternatif di luar sana?

Langkah 1: Aktifkan pemfilteran ARP di semua antarmuka:

# sysctl -w net.ipv4.conf.all.arp_filter=1
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf

Dari jaringan file / ip-sysctl.txt di Linux kernel docs:

arp_filter - BOOLEAN
    1 - Allows you to have multiple network interfaces on the same
    subnet, and have the ARPs for each interface be answered
    based on whether or not the kernel would route a packet from
    the ARP'd IP out that interface (therefore you must use source
    based routing for this to work). In other words it allows control
    of which cards (usually 1) will respond to an arp request.

    0 - (default) The kernel can respond to arp requests with addresses
    from other interfaces. This may seem wrong but it usually makes
    sense, because it increases the chance of successful communication.
    IP addresses are owned by the complete host on Linux, not by
    particular interfaces. Only for more complex setups like load-
    balancing, does this behaviour cause problems.

    arp_filter for the interface will be enabled if at least one of
    conf/{all,interface}/arp_filter is set to TRUE,
    it will be disabled otherwise

Langkah 2: Terapkan perutean berbasis sumber

Saya pada dasarnya hanya mengikuti arahan dari http://lartc.org/howto/lartc.rpdb.multiple-links.html , meskipun halaman itu ditulis dengan tujuan yang berbeda dalam pikiran (berurusan dengan dua ISP).

Asumsikan bahwa subnet adalah 10.0.0.0/24, gateway adalah 10.0.0.1, alamat IP untuk eth0 adalah 10.0.0.100, dan alamat IP untuk eth1 adalah 10.0.0.101.

Tentukan dua tabel routing baru bernama eth0 dan eth1 di / etc / iproute2 / rt_tables:

... top of file omitted ...
1    eth0
2    eth1

Tentukan rute untuk dua tabel ini:

# ip route add default via 10.0.0.1 table eth0
# ip route add default via 10.0.0.1 table eth1
# ip route add 10.0.0.0/24 dev eth0 src 10.0.0.100 table eth0
# ip route add 10.0.0.0/24 dev eth1 src 10.0.0.101 table eth1

Tetapkan aturan kapan menggunakan tabel routing baru:

# ip rule add from 10.0.0.100 table eth0
# ip rule add from 10.0.0.101 table eth1

Tabel routing utama sudah diurus oleh DHCP (dan bahkan tidak jelas bahwa ini sangat diperlukan dalam kasus ini), tetapi pada dasarnya sama dengan ini:

# ip route add default via 10.0.0.1 dev eth0
# ip route add 130.127.48.0/23 dev eth0 src 10.0.0.100
# ip route add 130.127.48.0/23 dev eth1 src 10.0.0.101

Dan voila! Segalanya tampak bekerja dengan baik. Mengirim ping ke kedua alamat IP berfungsi dengan baik. Mengirim ping dari sistem ini ke sistem lain dan memaksa ping untuk menggunakan antarmuka spesifik berfungsi dengan baik ( ping -I eth0 10.0.0.1, ping -I eth1 10.0.0.1). Dan yang paling penting, semua lalu lintas TCP dan UDP ke / dari salah satu alamat IP berfungsi seperti yang diharapkan.

Jadi sekali lagi, pertanyaan saya adalah: apakah ada cara yang lebih baik untuk melakukan ini? Ini sepertinya banyak pekerjaan untuk masalah yang tampaknya sederhana.

Pembaruan: Solusi di atas akhirnya tidak lengkap. Hal-hal bekerja dengan baik jika lalu lintas tetap pada subnet yang sama, tetapi komunikasi ke subnet lain menggunakan antarmuka ke-2 tidak akan berfungsi dengan baik. Daripada menggali lubang yang lebih besar, saya akhirnya berbicara dengan admin jaringan dan meminta mereka untuk memungkinkan beberapa alamat IP untuk satu antarmuka dan menggunakan IP aliasing (mis. Eth0 dan eth0: 0).

linux routing

— Scott Duckworth
sumber

Perbedaan utama untuk diingat adalah bahwa IP bukan milik antarmuka, itu milik mesin. Jadi sudah benar untuk mengirim antarmuka baik untuk IP dalam pengaturan ini, karenanya mengapa diperlukan beberapa tipu daya untuk tidak melakukannya.

— MikeyB

Saya percaya source routing tidak diperlukan dalam hal ini karena penyaringan arp hanya berlaku ketika saklar mengirim ke antarmuka / harus menemukannya di antara port-portnya. Saya bisa saja salah, tetapi ketika mesin mengirimkan data ke sakelar, IP di bidang sumber (IP header) tidak dicentang, hanya arp yang mengirim paket.

— AndreasM

MikeyB benar, sumber routing adalah satu-satunya cara. Mesin dapat memilih antarmuka keluar apa pun yang ingin dikirimkan lalu lintas, asalkan pada subnet yang sama. Tidak masalah jika IP tidak benar-benar terletak pada antarmuka itu atau tidak.

— Patrick

AndreasM: Paket yang masuk bukan masalah, itu paket keluar yang menjadi masalah. Tanpa sumber routing, semua paket keluar akan menggunakan rute default, yang terikat ke satu antarmuka atau yang lain. Meskipun paket keluar akan memiliki alamat IP sumber yang benar, filter pada sakelar tidak akan membiarkannya keluar karena alamat IP itu bukan milik alamat MAC dari antarmuka itu. Untuk beralih itu hanya terlihat seperti klien mencoba untuk menipu IP dari klien lain. (Ini adalah smart layer 3 switch).

— Scott Duckworth

Alias IP usang dan hack, tidak mencerminkan kenyataan, belum lagi bahwa menghapus primer akan menghapus semua alias. Gunakan ipdari iproute2untuk menambahkan lebih dari satu alamat ke antarmuka yang sama.

— pilona

Ya, cara yang lebih baik adalah membangun casing bisnis yang tepat, dan minta mereka mengendurkan aturan pada sakelar sehingga Anda dapat memiliki beberapa IP pada satu NIC.

— Zypher
sumber