使用一台 Linux 機器作為路由器和伺服器，在通過私有子網路由的公共 IP 上託管網站
我使用 Ubuntu 伺服器作為路由器、NATing 路由器和網路伺服器。伺服器通過公共 /29 子網連接到 ISP。我還託管了一些重要的網站。我要求 ISP 提供 ipv6 地址塊。他們說我的連結在 ISP 處終止的路由器不支持 ipv6。所以他們說如果我準備好通過私有 172.16.xx/30 子網連接到他們的邊緣路由器，他們可以為我提供 ipv6 塊。但是，他們會給我一個通過 172.16.xx/30 路由到我的公共 ipv4 /29，我可以用它來託管我的網站。但是我遇到的問題是我不想購買另一個路由器，以便我可以將 172.16.xx/30 放在面向 ISP 的介面上，將公共 /29 放在另一個面向我的伺服器和 NATing 路由器的介面上。
我想知道的是我是否可以使用 172.16.xx/30 連接到 ISP 並使用同一 Ubuntu 伺服器上的公共 /29 來託管網站和進行 NATing。我的路由器有超過 5 個網卡，我也可以使用 vlan。
ISP 的邊緣路由器支持 ipv6，但他們不能直接給我一個公共子網的原因是這個。目前，我的連結終止於通過 172.16.xx 連接到邊緣的交換機
如果在公共 Internet 上使用 RFC1918 地址進行路由器到路由器連接是不受歡迎的，尤其是在 ISP 和客戶之間的介面上使用時（而不是在 ISP 網路內的兩個路由器之間）。這是因為它們降低了 traceroute 的有用性，因為某些站點會阻止所有進出這些地址的數據包，並且因為無法通過 DNS PTR 記錄將有意義的名稱附加到這些地址，因為它們會導致路由器發起 ICMP 消息，而這些消息不能被追溯到他們的來源，可能還有其他原因。但是，聽起來您的 ISP 已設置為使用 RFC1918 /30 對他們與您之間的介面進行編號。儘管建議不要這樣做，但它實際上可以正常工作，並且您只需一個困難就可以適應這種情況（見下文）。
ISP 對大於 /30 的子網的 ARP 問題的抱怨聽起來很虛假。確實，路由器的性能可能會受到對具有大型稀疏子網的介面上不存在的地址的無用 ARP 請求的影響，但子網必須既大又稀疏（包含很多未使用的地址）才能發生這種情況。這是因為只有對子網上未使用的地址的 ARP 請求必須無休止地超時和重複，這就是路由器陷入困境的原因。如果他們將您的界面升級到（公共）/29，它既不會大也不會稀疏（我假設您實際上會使用/29 上的所有或幾乎所有地址）。
這個配置有一個好消息：因為 ISP 沒有在任何介面上配置你的 public /29，所以不需要保留塊的第一個和最後一個 IP 地址作為廣播地址，也不需要 ISP在他們自己的路由器上使用其中一個地址。因此，您可以為自己使用全部 8 個地址，而不僅僅是 5 個。
這是你要做的：
- 將面向 ISP 的介面配置為 ISP 提供的 172.16.xx/30 地址。
- 將 /29 塊添加到 lo 介面
/etc/network/interfaces：iface lo inet loopback up ip addr add a.b.c.d/29 dev lo
- 將預設網關設置為該連結 172.16.x.otherside 的 ISP 端。
現在出現了我之前提到的困難：預設情況下，當您的伺服器啟動出站連接（DNS 請求、電子郵件發出、軟體更新檢查、到數據庫的出站連接，或者您的伺服器執行的任何其他操作時，它是由自己而不是由客戶端啟動的聯繫伺服器），伺服器將使用 172.16.xx 作為數據包的源地址，因為這是連接到數據包要通過其出口的介面的地址。當伺服器嘗試使用此源地址聯繫整個 Internet 上的目的地時，它顯然無法正常工作。您需要為 route 命令提供一個選項以安裝具有自定義源地址的預設路由。
省略正常
gateway 172.16.x.otherside條目並在以下位置進行配置/etc/network/interfaces：iface ethSOMETHING inet static [other configuration directives] up ip route add default via 172.16.x.otherside src a.b.c.d對於
a.b.c.d，從您的 /29 中選擇一個您認為是伺服器“主”地址的地址。