Re: [問題] ISP的IP好像不是靠MAC記憶的？

看板Broad_Band作者s25g5d4 (function(){})()時間6年前 (2017/07/09 20:02)推噓6(6推 0噓 29→)

留言35則, 5人參與討論串2/2 (看更多)

※ 引述《LIAR (玻璃做的大叔)》之銘言： : 這問題單純是技術問題，倒不是說我非得固定IP或是要換IP，純粹好奇而已。 : 我用的是凱播cable。以往的經驗，因為分享器沒拔掉，一個IP可以用幾個月沒問題， : 之前看到有人想換IP，所以有高手提到DHCP的租約時間，還有MAC等問題。 : 我因為買了幾個行動基地台，還有centOS可以玩，我把大家的MAC都改成和我的分享器 : 一樣，有用過ifconfig確認或是接別台router確認過MAC，不過插到modem上面就 : 都是不同的IP。 : 我有把modem整個拔掉重新過電，只是拿到的IP還是本身機器原本拿到的， : 不同機器拿的IP就是不同，所以我認為應該不只MAC作用，請問有人知道 : 這種IP短時間的記憶，是靠什麼辦到的？剛好小弟大學時研究過一陣子 DHCP。（明明才剛畢業）這裡要談起 RFC 2131，也就是 DHCP 協定的標準。我不打算詳談內容與歷史，不過我要介紹一下 DHCP 協定的運作方式。 --- TL;DR: 你自己的裝置記憶之前的 IP，並且不要臉的跟伺服器要同一個 IP 來用。 -- 一個沒有錯誤發生的 DHCP 交涉會有四個階段（只算起始，不算更新與結束）： Client | Server | DHCPDISCOVER - | \ | ----- | \ | - DHCPOFFER | / ----- / | DHCPREQUEST - | \ | ----- | \ | - DHCPACK | / ----- / | -- Complete -- | 在 DISCOVER 階段，客戶端（client）以廣播或單播（極少）形式接觸伺服器端（server），伺服器端收到請求後自 IP 池（pool）隨機或某種方式選擇一個 IP 提供（OFFER）給客戶端。注意在 RFC 2131 定義的典型 DHCP 環境下具有容錯能力（fault tol- erance），因此 DHCP 伺服器可以有冗餘（或備援，redundancy）的伺服器，但是這樣就會產生競爭問題。例如伺服器 A 發了 IP 1 給 X，伺服器 B 也發了 IP 2 給 X，但是 X 只能選一個 IP 用。若沒有後續兩個階段來通知 A 或 B，那麼 IP 1 與 IP 2 其中一個必定會浪費掉，因為 A 或 B 無從得知 X 選了哪一個來用。另外還有多個競爭問題，後面會提到。客戶端收到 OFFER 回覆後，（若有多個）擇一使用並傳給發出該 OFFER 的伺服器 REQUEST 請求，伺服器確認此 IP 沒人使用（注意這裡有可能競爭）會給予客戶端 ACK 回覆，ACK 為 ACKnowledge 的意思。在特定情況下，由於發出 OFFER 時，該 IP 是不會註冊有人使用的（RFC定義），伺服器完全有可能發同一 IP 給 X 與 Y ，也因此才會設計 DHCPACK 回覆，若 X 請求先到就給 DHCPACK 回覆，Y 晚到給 DHCPNAK 回覆。NAK 為 Not AcKnowledge 的意思。那麼客戶端收到 ACK 之後就可以開始使用伺服器端提供的 IP 了嗎？不盡然。這是最後一個可能發生競爭的情況，就是當你取得的 IP 已經被占用的情況。這種狀況最有可能的發生原因有兩種： 1. 你的網路環境內有兩台以上 DHCP 伺服器，並且 IP 池有衝突，所以 A 伺服器發了 IP 1 給 X，但 B 伺服器不知道 IP 1 已經被占用，又把 IP 1 發給 Y。 2. 你室友嫌 DHCP 麻煩，直接設定一個固定 IP，但是 DHCP 伺服器不知道該 IP 被你室友搶走了，又把這個 IP 發給你。當然還有可能有別種情況，目前我就想到這樣。總之，在這種例外狀況發生時，客戶端發出 DHCPDECLINE 請求，並重新自 DISCOVER 階段開始。上面沒提到的還有兩種 DHCP 封包，DHCPINFORM 與 DHCPRELEASE。IN- FORM 適用在客戶端已有 IP，但缺少其他參數（例如 DNS 等），可以發出此請求。RELEASE 用在客戶端要離線了，主動把 IP 還回去。但很多情況下來不及發出 RELEASE 就斷線了，因此伺服器端不應該期待客戶會主動 RELEASE。接著我們來談談 DHCP 封包可以帶的東西。由上述可知 REQUEST 請求一定會帶有客戶端收到的 OFFER 給予的 IP，但是 DISCOVER 可不可以帶 IP 呢？可以！所以我們知道原 PO 的疑問了：原因是你的電腦自己請求同一個 IP。當然你會問：我換個環境就不一定能取得原本的 IP 了啊？沒錯，所以伺服器只會把你 DISCOVER 帶來的 IP 當作參考，不一定會發客戶端要求的那個 IP 給客戶。再來，我們來談談 DHCP Rapid Commit。我有看過 RFC 4039 的 Intro- duction，但後來我實作的時候根本沒碰過，所以就沒處理這種情況了。 Rapid commit 適用在單純的環境中，只有一個 DHCP 伺服器，允許伺服器直接跳過 OFFER 與 REQUEST 階段，直接發出 DHCPACK 給客戶端。印象中沒看過有 OS 預設會這樣做。另外客戶端有可能跳過 DISCOVER，直接自 REQUEST 階段開始。REQUEST 請求一定會帶有 IP 與租約時間，即使伺服器端沒發出 OFFER（或是很久以前發的），通常只要檢查 OK 伺服器端都會給 ACK。這種情況也是由客戶端主動帶 IP 給伺服器（可能是之前拿過的 IP），也符合原 PO 的敘述。值得一提的是當租約時間已過 1/2 時，多數客戶端會再次發起 REQUEST 請求，一樣伺服器檢查 OK 後給予 ACK。這樣做的原因是可以更新租約時間，也就是說假設這個 IP 我租 6 個小時，3 個小時過去我跟伺服器端再要一次 6 個小時。這樣就不會造成網路中斷，因為同一個 IP 一直更新租約，就可以一直用，不用過期後再重拿一個。這個行為稱為 renewal。萬一 IP 租約到期時也是先從 REQUEST 階段開始，拿到 NAK 才會回到 DISCOVER 階段。當然不一定是過半才更新租約，這個要看作業系統。最後，其實 DHCP 伺服器可以不只認 MAC 發 IP，有興趣可以查查 DHCP option 82。Option 82 帶兩個參數 circuit ID 與 remote ID，主要是設定在 DHCP forwarder 上面，當發生轉送（forward）時由 forwarder 偷插這兩個參數，給伺服器判斷。ISP 可以使用這個機制判斷客戶端從哪台機器／哪條線路／哪個孔上來，決定配哪個 IP 給你。另外 DHCP 可以帶的參數可多了，連主機名稱（hostname, option 12）、製造商訊息（vender spec. information, option 43）我都看過有客戶端傳過來（主要是 Windows）。不過這些都是可選項（optional），不是每個請求都會帶這些參數。 --

推

dkchronos

04/16 19:23,

04/16 19:23

推

cesar0909

04/16 19:42,

04/16 19:42

推

SNGoMMX

04/16 21:50,

04/16 21:50

→

y3k

04/16 21:53,

04/16 21:53

推

obov

04/16 22:20,

04/16 22:20

-- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.33.238.141 ※ 文章網址: https://www.ptt.cc/bbs/Broad_Band/M.1499601753.A.905.html ※ 編輯: s25g5d4 (114.33.238.141), 07/09/2017 20:07:32

→

crazycy

07/09 20:34, , 1^F

07/09 20:34, 1^F

→