Satu perkhidmatan hos perlu menjawab internet melalui pautan naik fizikal sementara semua yang lain pada mesin terus menggunakan terowong. Tiga syarat menentukan sama ada penghalaan berasaskan dasar mampu memikul beban itu, dan setiap satu murah untuk diperiksa sebelum anda menulis peraturan. Perkhidmatan mesti tamat pada hos ini dan bukan di belakang DNAT atau port yang diteruskan, peraturan VPN itu sendiri mesti membenarkan pengecualian, dan anda mesti memadankan balasan, bukan permintaan. Gagal mana-mana satu daripada tiga dan arahan di bawah dimuatkan dengan bersih tetapi tidak melakukan apa-apa yang berguna.

Periksa tiga syarat sebelum menulis peraturan

Kontena yang menerbitkan port melalui DNAT, atau pelayan di belakang penghantaran port, menghasilkan paket yang tidak berasal dari hos ini. Paket itu diteruskan, jadi peraturan yang berkunci pada input setempat hos tidak pernah melihatnya dan trafik terus mengambil laluan lalai. Sahkan di mana perkhidmatan benar-benar berjalan sebelum meneruskan, kerana inilah syarat yang paling kerap disalah fahami orang.

Syarat kedua ialah dasar, bukan mekanik. Mana-mana laluan yang memintas terowong ialah pengecualian kepada tujuan terowong, dan pada hos terurus keputusan itu milik pemilik dasar, bukan orang yang menyahpepijat had masa.

Padankan balasan, bukan port destinasi klien

Balasan daripada pelayan yang mendengar pada TCP 443 meninggalkan hos dengan port sumber 443. Pelayar pada hos yang sama yang menyambung ke laman HTTPS jauh menghantar port sumber sementara dan port destinasi 443. Kedua-duanya trafik port 443 dan hanya satu yang patut mengambil jadual WAN, sebab itulah pemadanan port destinasi akan menangkap separuh yang salah.

Arah balasan ialah apa yang anda boleh bezakan. Padankan port sumber, hadkan peraturan kepada paket yang dijana secara setempat, dan peraturan itu meliputi jawapan perkhidmatan itu sendiri tanpa menyentuh permintaan pelayar.

Bina jadual pulangan yang lengkap sebelum peraturan menunjuk kepadanya

Jadual kosong bermakna tiada laluan, yang kelihatan seperti perkhidmatan rosak, bukan dasar rosak. Isi dahulu, dengan nombor jadual dan keutamaan yang tiada apa-apa lain pada hos menuntutnya:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Baca nombor dari hos yang hidup dan bukan menyalinnya. ip -4 rule show memberitahu anda keutamaan mana yang telah diambil, dan menambah peraturan pada keutamaan yang sudah wujud secara senyap mengubah susunan dua peraturan yang kelihatan betul secara berasingan.

Dua pemilih melakukan kerja sebenar di sini. iif lo ialah cara kernel melaporkan paket yang dijana oleh hos sendiri, jadi peraturan tidak boleh menangkap trafik diteruskan yang datang dari luar secara tidak sengaja. ipproto tcp sport 443 menyempitkannya kepada satu pengangkutan dan satu port, yang seketat yang dibenarkan keperluan. Buang pemilih protokol dan peraturan juga menangkap UDP 443, iaitu perkhidmatan lain dengan tingkah laku berbeza.

Kekalkan balasan peribadi di dalam terowong

Jika pendengar yang sama juga menjawab klien di sebelah peribadi, laluan lalai WAN yang menangkap semua dalam jadual 100 akan cuba menghantar balasan itu kembali melalui pautan naik. Tambah awalan peribadi yang tidak boleh mengikut lalai WAN, atau biarkan ia jatuh ke peraturan dasar seterusnya:

ip -4 route add table 100 throw 10.90.0.0/24

Laluan throw menamatkan carian dalam jadual ini dan mengembalikan paket kepada senarai peraturan, jadi dasar VPN yang menyusul mendapat peluangnya. Ia sendiri tidak menghalakan apa-apa ke dalam terowong, dan jika tiada peraturan kemudian mempunyai laluan yang sepadan, paket itu masih gagal; sahkan dasar seterusnya dan bukannya menganggap throw ialah pembaikan.

Penapisan laluan songsang dan peraturan tembok api hos masih terpakai kepada permintaan yang tiba. Lihat keputusan sebenar mereka sebelum melonggarkan pengesahan, kerana pengecualian penghalaan tidak membuat rp_filter menerima laluan pulangan yang dianggapnya mustahil.

Uji TCP, kemudian QUIC, kemudian but semula

Buka satu sambungan dari klien luaran yang dibenarkan dan satu dari sebelah peribadi, kemudian periksa carian balasan dengan alamat dan port sebenar. Jika balasan luaran mengambil jadual 100 dan yang peribadi tidak, dasar itu melakukan apa yang anda minta.

HTTP/3 disajikan melalui UDP dan tidak akan dipadankan oleh peraturan TCP, jadi pendengar QUIC memerlukan pemilihnya sendiri, jika tidak ia akan terus menggunakan terowong sementara HTTPS berfungsi. Simpan peraturan yang anda tetapkan dengan komponen yang memiliki antara muka, dan sahkan selepas sambung semula atau pembaharuan DHCP. Apabila pengurus pesaing membuang laluan masa jalan selepas but semula, itu masalah pemilikan yang perlu dibaiki di punca, bukan alasan untuk menambah peraturan NAT yang lebih luas di atasnya.

Artikel berkaitan