Mengapa Laluan Tunnel Penuh Memutuskan Server yang Membawanya
Laluan lalai melalui tunnel turut menangkap paket luar yang membawanya. Pin titik akhir dengan laluan hos dan pastikan balasan pelayan kekal di luarnya.
Hidupkan tunnel penuh dan setiap destinasi kini milik antara muka VPN, termasuk mesin yang menamatkannya. Paket luar yang membawa tunnel dialamatkan kepada mesin itu, jadi laluan akhirnya memakan pengangkutan yang menjadi kebergantungannya. Satu laluan khusus tambahan menyelesaikannya, dan sebabnya wajar difahami. Tanpa sebab itu, pembinaan semula seterusnya akan memasukkan semula kerosakan yang sama.
Laluan yang memakan pengangkutannya sendiri
Enkapsulasi membungkus setiap paket dalam pengepala kedua. Yang luar dialamatkan dari alamat fizikal tempatan ke alamat awam pelayan, dan ia mesti melintasi pautan fizikal sebelum mana-mana tunnel boleh wujud.
Sekarang biarkan carian untuk alamat awam itu memilih tunnel. Untuk menghantar paket, mesin mesti mengenkapsulasikannya, yang memerlukan laluan ke alamat yang sama, dan laluan itu mengembalikan tunnel. Klien mengendalikannya dengan salah satu daripada dua cara. Yang berhati-hati enggan memasang laluan lalai dan melaporkan ralat, manakala yang kurang berhati-hati melaporkan kejayaan lalu tidak mengalihkan apa-apa. Kegagalan senyap itulah yang memakan satu petang.
Padanan awalan terpanjang menentukan carian sebelum sebarang metrik dilihat, jadi laluan satu alamat mengatasi setiap laluan lalai pada mesin. Itulah keseluruhan mekanisme di sebalik pembaikan.
Pasang pengecualian sebelum laluan lalai
Cipta laluan satu alamat untuk pelayan, dengan gateway fizikal sebagai hop seterusnya, sebelum laluan lalai bergerak. Urutan penting: memasangnya kemudian bermakna hidup dengan tunnel yang rosak semasa anda menaip.
Kebanyakan klien melakukan ini tanpa diminta. OpenVPN mencari alamat jauh dan meminnya sebelum menulis semula gateway lalai, dan pilihan route-delay-nya wujud untuk platform yang urutan itu bersaing. wg-quick mengambil jalan yang sama sekali berbeza, menandakan paket dan merujuk peraturan dasar dan bukannya menambah pengecualian. Mekanisme berbeza, keperluan sama: paket luar mesti terlepas daripada tunnel yang diciptanya.
ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10
Output carian ialah ujian penerimaan. Ia mesti menamakan peranti fizikal dan hop seterusnya yang fizikal. Peranti tunnel dalam jawapan itu bermakna pengecualian tiada, atau diletakkan selepas sesuatu yang mengatasinya.
Imej cermin pada pelayan
Perangkap yang sama menunggu di sebelah sana, terbalik. Beri pelayan laluan lalai melalui tunnel lain, atau tolak kepadanya laluan yang meliputi alamat awam klien, dan balasannya akan mendapat tabiat arah yang salah.
Bayangkan klien yang menyambung dan menghantar permintaan. Balasan dialamatkan ke alamat awam klien itu, yang kini sepadan dengan laluan tunnel, jadi ia keluar dari antara muka lain sambil membawa sumber yang tidak pernah didail klien. Klien boleh menerima paket itu dan tetap membuangnya, kerana tiada apa yang mengikatnya kepada permintaan yang dihantar. Mulakan daripada keputusan penghalaan pelayan dan bukan daripada tamat masa klien, kerana hanya satu daripadanya menunjukkan pilihan sebenar.
ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44
Terdapat tiga pembaikan dan ia tidak setara. Memin perkhidmatan pada alamat fizikal, atau menterjemah sumber, kedua-duanya menyembunyikan keputusan penghalaan dan bukannya membetulkannya. Menghantar trafik balasan untuk kolam tunnel melalui jadual khusus membetulkan puncanya, dan dua yang lain hanya boleh diterima selagi reka bentuk penghalaan dibekukan.
Pengecualian yang terus dicuri oleh tunnel
Sebilangan kecil tugasan memerlukan internet terbuka walaupun tunnel memiliki laluan lalai, dan setiap satu memerlukan pengecualian sendiri. Pengemas kini DNS dinamik biasanya yang pertama rosak.
Ia menyelesaikan penyedia, membuka sambungan dan mendapati paketnya sendiri bergerak melalui tunnel yang alamatnya berubah beberapa saat lalu, jadi kemas kini gagal atau menerbitkan alamat yang salah. Tiga jalan keluar: pin penyedia dengan laluan hos melalui gateway fizikal, jalankan kemas kini sebelum tunnel naik, atau beri pengemas kini jadual dasar yang tidak pernah disentuh tunnel. Penyegerakan masa mempunyai pendedahan yang sama pada peranti yang but tanpa penyelesai, dan titik akhir pengesahan sijil tergolong dalam senarai atas sebab yang sama.
Pengecualian yang tiada siapa tulis ialah pengecualian yang akan digugurkan secara senyap oleh pembinaan semula seterusnya.
Buktikan selepas sambung semula, bukan sebelum
Uji tiga destinasi, bukan satu: titik akhir, alamat peribadi di belakang tunnel, dan alamat awam di sebaliknya. Satu carian yang berjaya hampir tidak memberitahu apa-apa tentang dua yang lain.
ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1
Kemudian mulakan semula sambungan, kerana klien yang membina semula jadualnya semasa sambung semula akan membuang laluan yang anda taip dengan tangan. Dengan kill switch aktif, periksa bahawa titik akhir dibenarkan, jika tidak tunnel tidak boleh kembali selepas perubahan rangkaian dan gejalanya kelihatan seperti gangguan. Simpan pengecualian dalam profil atau fail unit dan bukan dalam sejarah shell, supaya sambung semula menciptanya semula dan bukannya memadamkannya.