作者：林風(fēng)<droplet@163.net>
出處：http://www.nsfocus.com
日期：2003-07-02
本文是上一篇文章《LINUX2.4.x網(wǎng)絡(luò )安全框架》的后續文章，主要分析連接跟蹤和地址轉換在LINUX2.4.x中的實(shí)現，本文引用代碼是LINUX2.4.20。
1. 概述
在上一篇文章中我們提到LINUX2.4.x的網(wǎng)絡(luò )安全實(shí)現較之LINUX2.2.x有了很大的改進(jìn)，其中的兩個(gè)重要改進(jìn)一是增加了連接跟蹤的功能，二是增強了地址轉換功能的實(shí)現。由于地址轉換功能是在連接跟蹤的基礎上實(shí)現的，所以把這兩個(gè)模塊放在一起來(lái)分析。
連接跟蹤（CONNTRACK），顧名思義，就是跟蹤并且記錄連接狀態(tài)。這里的連接并不僅僅指TCP連接，它也包括UDP、ICMP等協(xié)議的虛擬連接。連接跟蹤是實(shí)現地址轉換的基礎，在使用地址轉換功能時(shí)必須加載這個(gè)模塊。
增強的地址轉換實(shí)現了一個(gè)全功能的地址轉換模塊。在LINUX2.2.x中只有地址偽裝和透明代理，目的轉換還是在地址偽裝基礎上實(shí)現的。在LINUX2.4.x中，源轉換（SNAT）包括了地址偽裝和源地址轉換，目的轉換(DNAT)包括了透明代理和目的地址轉換，并且這些功能是在同一個(gè)框架下實(shí)現的，代碼結構比以前清晰，可擴展性更強。
2. 檢查點(diǎn)以及檢查點(diǎn)上的函數
先來(lái)看看連接跟蹤和地址轉換在檢查點(diǎn)上注冊了相應的結構，如圖：
[圖1.1 IPV4的功能點(diǎn)在各檢查點(diǎn)上注冊的結構]
在圖中，我們可以看到不同的數據包所要經(jīng)過(guò)的三條路徑：
·發(fā)往本機上層的包：經(jīng)過(guò)的檢查點(diǎn)是NF_IP_PRE_ROUTING，NF_IP_LOCAL_IN。
·由本機轉發(fā)的包：經(jīng)過(guò)的檢查點(diǎn)是NF_IP_PRE_ROUTING，NF_IP_FORWARD，NF_IP_POST_ROUTING。
·從本機發(fā)出的包：NF_IP_LOCAL_OUT，NF_IP_POST_ROUTING。
在每一條路徑上，連接跟蹤和地址轉換都注冊了相應的函數，并創(chuàng )建與之相關(guān)的數據結構，完成其功能。每條路徑上功能點(diǎn)的順序如圖所示：
[圖1.2 路徑上功能點(diǎn)的順序]
在這個(gè)圖中，CONNTRACK代表連接跟蹤，DNAT代表目的轉換，SNAT代表源轉換，FILTER代表包過(guò)慮?？梢钥吹?，CONNTRACK在路徑上出現了兩次，其作用是：第一個(gè)點(diǎn)上它創(chuàng )建連接跟蹤的結構，這個(gè)結構會(huì )在后面的地址轉換和包過(guò)濾中被使用，在第二個(gè)點(diǎn)上它將連接跟蹤的結構加到系統的連接表中。
檢查點(diǎn)上注冊的函數如下圖所示：
[圖1.3 連接跟蹤和地址轉換在檢查點(diǎn)上調用的函數]
圖中用粗體字標識連接跟蹤的函數，用斜體字標識地址轉換的函數，括號里面的函數名是實(shí)際調用的函數的名稱(chēng)。這些函數在檢查點(diǎn)上被調用。下面將分析這些函數的實(shí)現以及其中所涉及的重要數據結構和過(guò)程。
3. 連接跟蹤的重要數據結構和過(guò)程
連接跟蹤記錄連接的狀態(tài)，并且實(shí)現狀態(tài)間的轉換。連接并不只是指TCP協(xié)議連接，它也包括UDP協(xié)議和ICMP協(xié)議。當然這只是內核的標準實(shí)現中包含的協(xié)議，其他協(xié)議的連接跟蹤可以自己添加到內核中。連接的數據結構如下：
struct ip_conntrack
{
struct nf_conntrack ct_general; /* 結構的引用計數 */
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX]; /* 不同方向上的計算哈希值的參數*/
volatile unsigned long status; /* 結構的狀態(tài) */
struct timer_list timeout;
struct list_head sibling_list; /* 與此結構關(guān)聯(lián)的expect鏈表*/
unsigned int expecting; /* 與此結構關(guān)聯(lián)的expect的數量*/
struct ip_conntrack_expect *master; /* 指向創(chuàng )建此結構的expect */
struct ip_conntrack_helper *helper; /* 與此結構關(guān)聯(lián)的helper */
struct nf_ct_info infos[IP_CT_NUMBER]; /* 不同狀態(tài)下由skb引用 */
union ip_conntrack_proto proto;
union ip_conntrack_help help;
struct {
struct ip_nat_info info;
union ip_conntrack_nat_help help;
int masq_index;
} nat; /* 與地址轉換相關(guān)的結構 */
};
在這個(gè)結構中tuplehash[]記錄了此連接的正反兩個(gè)方向包的參數，這些參數包括協(xié)議、源地址/源端口、目的地址/目的端口等，如果沒(méi)有端口，比如ICMP協(xié)議，就用它的id，type，code等代替。每個(gè)連接都根據這些參數計算哈希值并連接到一個(gè)全局的哈希表中。連接是雙向的，所以每個(gè)連接在哈希表中出現兩次，匹配連接和應答兩個(gè)方向上的包。
前面說(shuō)到，對不同協(xié)議，連接跟蹤記錄的參數不同，所以不同的協(xié)議定義了不同的 ip_conntrack_protocol結構來(lái)處理與協(xié)議相關(guān)的內容。這些結構被注冊到一個(gè)全局的鏈表中，在使用時(shí)根據協(xié)議去查找，并調用相應的處理函數來(lái)完成相應的動(dòng)作。下面將要講到的ip_nat_protocol的作用與此類(lèi)似，它處理的是與協(xié)議相關(guān)的地址轉換方面的內容。
不同協(xié)議連接跟蹤的過(guò)程不同。
TCP的連接跟蹤可以用下面的表來(lái)說(shuō)明：（假設是A到B的TCP連接）
發(fā)包的方向 標志位 連接狀態(tài) 說(shuō)明
A--> B SYN IP_CT_NEW A發(fā)起連接
B-->A SYN/ACK IP_CT_ESTABLISHED B響應A的連接請求
+ IP_CT_IS_REPLY
A-->B ACK IP_CT_ESTABLISHED A確認B的響應
[表2.1 TCP建立連接的狀態(tài)變遷]
這個(gè)表說(shuō)明的是創(chuàng )建TCP連接所經(jīng)歷的狀態(tài)變遷。表中沒(méi)有顯示刪除TCP連接所經(jīng)歷的狀態(tài)，這是因為刪除TCP連接是通過(guò)超時(shí)執行的，任何狀態(tài)下都可以刪除連接，所以并不需要額外的狀態(tài)變遷。
對TCP連接，還有一個(gè)TCP的狀態(tài)變遷。它和連接的狀態(tài)不同，它記錄了TCP協(xié)議的狀態(tài)轉換，其中涉及更多與TCP連接相關(guān)的狀態(tài)。并且超時(shí)也是在這個(gè)狀態(tài)基礎上賦值的。具體的實(shí)現可以參考源代碼。
除了上面列出的狀態(tài)外，還有一個(gè)重要的狀態(tài)IP_CT_RELATED。這個(gè)狀態(tài)用于創(chuàng )建動(dòng)態(tài)連接時(shí)使用。動(dòng)態(tài)連接有兩類(lèi)，一是處理使用了動(dòng)態(tài)地址或端口的應用協(xié)議；二是針對TCP、UDP、ICMP等協(xié)議的ICMP差錯報文。動(dòng)態(tài)連接與原連接相關(guān)，所以用了一個(gè)特殊的狀態(tài)來(lái)標識它們。
UDP的連接跟蹤可以用下面的表來(lái)說(shuō)明：
發(fā)包的方向 連接狀態(tài) 說(shuō)明
A-->B IP_CT_NEW A到B的UPD包
B-->A IP_CT_ESTABLISHED B到A的UDP包（端口與A到B的包相反）
+ IP_CT_IS_REPLY
[表2.2 UDP的狀態(tài)變遷]
UDP本來(lái)是一個(gè)無(wú)狀態(tài)的協(xié)議，連接跟蹤記錄的的是兩個(gè)方向上的UDP包，并且不同狀態(tài)下，連接的超時(shí)值不同。
ICMP的連接跟蹤可以用下面的表來(lái)說(shuō)明：
發(fā)包的方向 連接狀態(tài) 說(shuō)明
A-->B IP_CT_NEW A到B的ICMP查詢(xún)包
B-->A IP_CT_ESTABLISHED B到A的對ICMP查詢(xún)包的應答包
+ IP_CT_IS_REPLY
[表2.3 ICMP的狀態(tài)變遷]
ICMP協(xié)議也是一個(gè)無(wú)狀態(tài)的協(xié)議，連接跟蹤記錄的是ICMP的查詢(xún)包和查詢(xún)應答包，只有在記錄了查詢(xún)包的情況下才允許相應的應答包通過(guò)。
為了處理應用協(xié)議里面的動(dòng)態(tài)地址和端口，每個(gè)使用動(dòng)態(tài)地址和端口的協(xié)議一般都定義了數據結構ip_conntrack_helper，并把它放到一個(gè)全局的鏈表中。這類(lèi)協(xié)議一般都會(huì )有控制連接和數據連接兩個(gè)不同的連接，如FTP協(xié)議。而在這個(gè)結構中定義了匹配其協(xié)議控制連接的參數，當創(chuàng )建或更新結構ip_conntrack時(shí)都會(huì )查找鏈表中有沒(méi)有相應的ip_connctrack_helper結構，如果存在，就把它的指針賦給ip_conntrack里面的helper。ip_conntrack_helper里面的函數會(huì )根據協(xié)議里的地址和端口創(chuàng )建與控制連接相關(guān)的結構ip_conntrack_expect，并且在有應答時(shí)根據ip_conntrack_expect得到相應數據連接的參數。ip_conntrack與ip_conntrack_expect的關(guān)系可以用下圖來(lái)表示：
[2.1 ip_conntrack和ip_conntrack_expect的關(guān)系]
在helper里并沒(méi)有直接創(chuàng )建ip_conntrack結構，而是創(chuàng )建了一個(gè)過(guò)渡的結構ip_conntrack_expect，并把它放到了一個(gè)全局的鏈表中。接著(zhù)，當建立數據連接時(shí)，再找到這個(gè)ip_conntrack_expect結構，并把它與新建的ip_conntrack結構連接起來(lái)。
連接跟蹤主要在ip_conntrack_in和ip_confirm這兩個(gè)函數里實(shí)現。在ip_conntrack_in里面創(chuàng )建ip_conntrack結構。接下來(lái)，地址轉換改動(dòng)數據包里的地址，包過(guò)濾會(huì )禁止包通過(guò)。如果這個(gè)包能夠到達ip_confirm，由它把相應的ip_conntrack結構加到系統的哈希表中。ip_conntrack_in函數在文件ip_conntrack_core.c中，下面是它的一個(gè)修改后的版本，每行前的行號與原文件里的行號相同。
unsigned int ip_conntrack_in
{
804 (*pskb)->nfcache |= NFC_UNKNOWN;
823 if ((*pskb)->nfct)
824 return NF_ACCEPT;
指針pskb指向傳入函數的數據包，第804行設置這個(gè)數據包的標記為NFC_UNKNOWN，說(shuō)明它沒(méi)有被修改過(guò)。同類(lèi)的標記還有NFC_ALTERED，用于說(shuō)明這個(gè)數據包已被修改過(guò)。在連接跟蹤里不會(huì )修改數據包的任何參數，所以把它的標記置為NFC_UNKNOWN。第823行檢查這個(gè)數據包是否已被檢查過(guò)了，因為已檢查過(guò)的數據包它的nfct成員指向它所屬的ip_conntrack結構里的infos[]中的某一成員，以說(shuō)明這個(gè)數據包是此連接的哪個(gè)狀態(tài)下收到的包。
827 if ((*pskb)->nh.iph->frag_off & htons(IP_MF|IP_OFFSET)) {
828 *pskb = ip_ct_gather_frags(*pskb);
829 if (!*pskb)
830 return NF_STOLEN;
831 }
第827-831行進(jìn)行分片重組。在LINUX2.4.x網(wǎng)絡(luò )安全的實(shí)現中，分片重組是自動(dòng)進(jìn)行的，并不需要打開(kāi)像LINUX2.2.x中ip_always_defrag那樣的開(kāi)關(guān)。
833 proto = ip_ct_find_proto((*pskb)->nh.iph->protocol);
836 if ((*pskb)->nh.iph->protocol == IPPROTO_ICMP
837 && icmp_error_track(*pskb, &ctinfo, hooknum))
838 return NF_ACCEPT;
第833-838行找到與數據包協(xié)議相同的ip_conntrack_protocol結構，并且如果協(xié)議是ICMP則調用icmp_error_track做特殊處理。
840 if (!(ct = resolve_normal_ct(*pskb, proto,&set_reply,hooknum,&ctinfo)))
841 return NF_ACCEPT;
850 ret = proto->packet(ct, (*pskb)->nh.iph, (*pskb)->len, ctinfo);
851 if (ret == -1) {
853 nf_conntrack_put((*pskb)->nfct);
854 (*pskb)->nfct = NULL;
855 return NF_ACCEPT;
856 }
第840-856行根據數據包中的參數在全局的連接表中查找與此包匹配的連接結構。前面說(shuō)過(guò)，連接結構在連接表中出現兩次，代表連接的兩個(gè)方向。如果沒(méi)有找到相應的連接，則創(chuàng )建新的連接。新的連接創(chuàng )建之后，需要查找ip_conntrack_expect_list看看是否這個(gè)連接是與控制連接相關(guān)的數據連接。同時(shí)還要查找ip_conntrack_helper的鏈表，看看此連接是否有與之關(guān)聯(lián)的ip_conntrack_helper結構。
858 if (ret != NF_DROP && ct->helper) {
859 ret = ct->helper->help((*pskb)->nh.iph, (*pskb)->len, ct, ctinfo);
861 if (ret == -1) {
863 nf_conntrack_put((*pskb)->nfct);
864 (*pskb)->nfct = NULL;
865 return NF_ACCEPT;
866 }
867 }
第858-867行調用與連接關(guān)聯(lián)的ip_conntrack_helper中的函數處理協(xié)議中的動(dòng)態(tài)地址和端口。
ip_confirm函數實(shí)際調用的是函數__ip_conntrack_confirm，在調用之前它會(huì )先確認相關(guān)連接是否已經(jīng)在全局的哈希表中，如果已經(jīng)在了，就返回。__ip_conntrack_confirm函數在文件ip_conntrack_core.c中，下面是它的一個(gè)修改過(guò)的版本，每行前的行號是原文件中的行號。
int__ip_conntrack_confirm(struct nf_ct_info *nfct)
{
426 ct = __ip_conntrack_get(nfct, &ctinfo);
432 if (CTINFO2DIR(ctinfo) != IP_CT_DIR_ORIGINAL)
433 return NF_ACCEPT;
第426行從數據包的nfct變量中得到它所屬的ip_conntrack結構，第432行檢查此時(shí)的連接狀態(tài)是否是IP_CT_DIR_ORIGINAL方向，也就是創(chuàng )建此連接包的方向上的狀態(tài)，如果不是，返回。
435 hash = hash_conntrack(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
436 repl_hash = hash_conntrack(&ct->tuplehash[IP_CT_DIR_REPLY].tuple);
第435-436行計算兩個(gè)方向上的哈希值。
448 WRITE_LOCK(&ip_conntrack_lock);
452 if (!LIST_FIND(&ip_conntrack_hash[hash],
conntrack_tuple_cmp,
struct ip_conntrack_tuple_hash *,
&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, NULL)
456 && !LIST_FIND(&ip_conntrack_hash[repl_hash],
conntrack_tuple_cmp,
struct ip_conntrack_tuple_hash *,
&ct->tuplehash[IP_CT_DIR_REPLY].tuple, NULL)) {
460 list_prepend(&ip_conntrack_hash[hash],
&ct->tuplehash[IP_CT_DIR_ORIGINAL]);
462 list_prepend(&ip_conntrack_hash[repl_hash],
&ct->tuplehash[IP_CT_DIR_REPLY]);
470 WRITE_UNLOCK(&ip_conntrack_lock);
471 return NF_ACCEPT;
472 }
474 WRITE_UNLOCK(&ip_conntrack_lock);
475 return NF_DROP;
}
第448－475行將連接加到全局的哈希表中。在加入之前，先要確認它不在哈希表中，而且要把表鎖住，禁止其他內核路徑讀或寫(xiě)哈希表。如果加入成功，則返回NF_ACCEPT，如果不成功，則返回NF_DROP。
4. 地址轉換的重要數據結構和過(guò)程
地址轉換與連接跟蹤緊密相關(guān)。事實(shí)上，與地址轉換相關(guān)的數據也就放在ip_conntrack結構里面，它的內容如下：
struct ip_nat_info
{
int initialized;
unsigned int num_manips; /* 需要改動(dòng)的tuple的個(gè)數 */
struct ip_nat_info_manip manips[IP_NAT_MAX_MANIPS]; /* 在不同檢查點(diǎn)上修改后的地址和端口*/
const struct ip_nat_mapping_type *mtype; /* 地址轉換的類(lèi)型 */
struct ip_nat_hash bysource, byipsproto; /* 鏈接到哈希表 */
struct ip_nat_helper *helper; /* 與此相關(guān)的helper */
struct ip_nat_seq seq[IP_CT_DIR_MAX];
};
結構中manips[]保存的是修改后的地址和端口（這與協(xié)議有關(guān)，比如說(shuō)ICMP協(xié)議里面修改可能是id，type，code等。前面提到的ip_nat_protocol結構就是處理與協(xié)議相關(guān)的參數的），這些地址用來(lái)替代原包中的地址或端口。
bysource，byipsproto兩個(gè)成員把它所在ip_conntrack鏈接到兩個(gè)哈希表中。這兩個(gè)哈希表，一個(gè)用于源地址轉換，一個(gè)用于目的地址轉換。
如前所述，ip_nat_helper處理應用協(xié)議里的動(dòng)態(tài)地址和端口，這個(gè)helper與前面提到的ip_conntrack_helper是配合起來(lái)使用的。ip_conntrack_helper創(chuàng )建與ip_conntrack相關(guān)的ip_conntrack_expect結構，然后再由ip_conntrack_helper修改其中的地址和端口。
完成地址轉換的主要函數是ip_nat_fn。在這個(gè)函數里，根據manips[]的信息修改包的地址或端口。manips[]里面的參數的填充主要來(lái)自?xún)蓚€(gè)方面：一是匹配相應的地址轉換規則（由ip_nat_rule_find查找），匹配到相應的規則后，規則里的TARGET會(huì )將相應的信息填充到manips[]中；還有一個(gè)就是由ip_conntrack_helper創(chuàng )建ip_conntrack結構，它的完整信息由ip_nat_helper里的expect函數填充。填充ip_nat_info里參數的函數是ip_nat_setup_info，在這個(gè)函數里為ip_nat_info選擇唯一的地址和端口，如果有多個(gè)可選地址，還可以做簡(jiǎn)單的負載均衡。
ip_nat_fn函數在文件ip_nat_standalone.c中，下面是它的一個(gè)修改過(guò)的版本。
ip_nat_fn
{
79 (*pskb)->nfcache |= NFC_UNKNOWN;
85 ct = ip_conntrack_get(*pskb, &ctinfo);
第79行設置skb的標志，這個(gè)標志是暫時(shí)的，因為地址轉換要修改數據包里的參數，所以在改動(dòng)之后，這個(gè)標志會(huì )設置為NFC_ALTERED。第85行是得到與此包關(guān)聯(lián)的ip_contrack結構。
103 switch (ctinfo) {
111 case IP_CT_NEW:
118 info = &ct->nat.info;
120 WRITE_LOCK(&ip_nat_lock);
123 if (!(info->initialized & (1 << maniptype))) {
127 if (ct->master
&& master_ct(ct)->nat.info.helper
&& master_ct(ct)->nat.info.helper->expect) {
130 ret = call_expect(master_ct(ct), pskb,
hooknum, ct, info);
132 } else {
133 ret = ip_nat_rule_find(pskb, hooknum, in, out,
ct, info);
135 }
第103-135行填充ip_nat_info結構，這里有兩種情況。對創(chuàng )建ip_conntrack結構的包，因為是它的ip_nat_info結構還沒(méi)有初始化，所以調用ip_nat_rule_find去查找相應的地址轉換規則，這個(gè)函數又會(huì )調用ipt_do_table函數。如果這個(gè)ip_conntrack結構是由ip_conntrack_helper創(chuàng )建的，則調用它的控制連接的ip_nat_helper中的expect函數填充數據連接中ip_nat_info中的參數。如果相應的ip_nat_info結構已經(jīng)填充過(guò)了，則跳過(guò)這部分處理。
142 if (in_hashes) {
144 replace_in_hashes(ct, info);
145 } else {
146 place_in_hashes(ct, info);
147 }
148 }
152 WRITE_UNLOCK(&ip_nat_lock);
第142-152行根據新的地址和端口將ip_conntrack放到全局的哈希表中，或者從哈希表中將使用舊參數的ip_conntrack取下來(lái)，并使用新的參數把它重新放到哈希表中。
163 return do_bindings(ct, ctinfo, info, hooknum, pskb);
第163行的do_bindings函數完成數據包的修改，并且如果ip_conntrack上有與之相關(guān)的ip_nat_helper，則調用的help函數處理應用協(xié)議里的數據。
5. 連接跟蹤、地址轉換與包過(guò)濾的關(guān)系
LINUX2.4.x中的連接跟蹤和包過(guò)濾是兩個(gè)獨立的功能。連接跟蹤創(chuàng )建的連接結構并不作為允許或禁止包通過(guò)的依據，只是在包過(guò)濾中可以匹配連接跟蹤里面的狀態(tài)，進(jìn)而決定允許或禁止包通過(guò)。這一點(diǎn)與一般意義上的狀態(tài)檢測不同。在狀態(tài)檢測里面，如果有相應的連接存在，就不檢查過(guò)濾規則，只進(jìn)行相應的狀態(tài)變遷。在LINUX2.4.x中，不管連接跟蹤的狀態(tài)如何，都要去檢查過(guò)濾規則才能決定是否允許包通過(guò)。其檢查效率要差一些。
從前面的檢查點(diǎn)的順序圖可以看出，包過(guò)濾是在目的轉換之后，源轉換之前進(jìn)行的，所以在添加過(guò)濾規則時(shí)，規則中的目的地址要用轉換后的地址，也就是數據包真正的目的地，而不是包中原來(lái)地目的地址。
6. 小結
以上是對LINUX2.4.x中連接跟蹤和地址轉換實(shí)現的簡(jiǎn)單分析。在分析中我們可以看到，在這個(gè)實(shí)現里面，有許多可以擴展的東西：如ip_conntrack_protocol，ip_nat_protocol，ip_conntrack_helper，ip_nat_helper等。加上上一篇介紹的ipt_table，ipt_match，ipt_target，nf_hook_ops等。LINUX2.4.x網(wǎng)絡(luò )安全的實(shí)現就是建立在這些可擴展結構的基礎之上，所以它有很好的可擴展性。并且，針對不同的協(xié)議定義的不同的結構處理與協(xié)議相關(guān)的信息，使得信息隱蔽性好，模塊化增強。這正是一個(gè)出色的框架所具備的特點(diǎn)。不過(guò)它并沒(méi)有實(shí)現真正意義上的狀態(tài)檢測，而且它的包過(guò)濾的效率也有待改進(jìn)。
參考資料：
1：LINUX2.4.20內核源代碼
2：Netfilter Hacking HOWTO
2： iptables tutorial by Oskar Andreasson
3：Iptables connection tracking by James C. Stephens.
作者簡(jiǎn)介：
林風(fēng)，獨立撰稿人。熟悉LINUX網(wǎng)絡(luò )安全技術(shù)。比較感興趣的方向是網(wǎng)絡(luò )協(xié)議棧的實(shí)現。寫(xiě)文章，是為整理思路，發(fā)現問(wèn)題，與更多人分享經(jīng)驗，知識，或者教訓。郵件地址是droplet@163.net，歡迎批評，鼓勵或指正。
